igrigorik: ric: updates landed, no substantative changes
plh: will review and chat with director, if there is push back we can republish as CR
... also callback suspended test needs two passing implementations
<scribe> ACTION: Ilya + Ross to investigate ric failing test on Chrome side
plh: we'll publish draft to TR
... once we publish FPWD, we need to setup auto-republish
shubhie: did a test for long tasks yesterday, seems to have worked; need to setup for first-paint
... also need to setup device memory
RESOLUTION: publish FPWD for Long Tasks and Paint Timing
<scribe> ACTION: plh to setup publishing for LT, PT, Device Memory
plh: what status of tests?
shubhie: we have tests for long tasks
... for paint timing we need some extra work in WPT to land those
Tim: Nicholas (on Chrome side) is working on paint timing tests
shubhie: long tasks tests should be upstreamed in WPT
<plh> http://wpt.fyi/longtask-timing
scribe: failing test for LT: we're simulating long task by running a long script, but they get joined together.. and test machinery itself generates some long tasks
Yoav: how flaky are LT tests?
Shubhie: seem to be A-ok
Yoav: the big hurdle was defining the preload cache as part of Fetch spec
... but this is fetch spec work, which won't impact the behavior of preload API
... I think it shouldn't block L1 CR
<plh> http://wpt.fyi/beacon
plh: what kind of tests do we have for caching?
Yoav: we have tests, FF modified their tests when they shipped because our tests did not match their caching behavior
... current tests in WPT pass in Chrome and FF
... once Fetch patch for preload cache is merged it will highlight implementation differences
... FF changed behavior to pass in both
<yoav> http://wpt.fyi/preload
scribe: current tests ignore caching differences
plh: CR sounds reasonable, we have two implementations.. how long do we stay there?
toddreif: preload is coming, eta ~3~4 months in insider builds
... I don't see any good reason to block CR from our side
plh: once we have in CR, how long do we stay in CR?
toddreif: any critical pushback (if any) we'll have before end of year
plh: at TPAC we can put on agenda to move to PR
RESOLUTION: publish preload as CR
<scribe> ACTION: plh to publish CR
<plh> https://lists.w3.org/Archives/Public/spec-prod/2017JulSep/0005.html
dale: found some issues with current test
... there is potential ambiguity in the spec, need to dig in more
todd: one issue is that time origin starts when dialogue prompts.
todd: we're blocked on release, WIP
todd: Luis was blocked on GitHub, should be coming
todd: Long Tasks slipped through for next release, don't have any substantive feedback yet
... need to circle back internally with folks for strings describing different long tasks
shubhie: current proposal is captured in the latest spec; subset of those match our implementation
... also need to check-in with other browsers
... as a starting point, some feedback on current strings
<scribe> ACTION: Todd to gather feedback for next call
shubhie: too many tabs, limited resources
... background tabs and windows end up hurting user experience
... we want to define lifecycle to allow UA to optimize foreground activity, while allowing legitimate background activity
... the goal is to reduce memory pressure, improve user experience
... current lifecycle is fragmented
... ideally, we need to allow apps to persist state, session wrapup, analytics and reporting, and background work
... idea is to use native app as inspiration
... iOS has 5 states, android has a number of activity transitions (~5 with callbacks in each transition)
... on the web we have PV and pagehide/show, bot those have gaps, especially on mobile
... core ideas: system initiated termination is normal part of lifecycle
... + apps in background can be stopped and terminted
... + we need callbacks on these transitions
... active -> passive -> backgrounded > stopped
... stopped already exists in soem browsers -- e.g. bfcache
... proposal is to reuse existing callbacks
... use pagehide and show for stopped
stopped to discarded -> unload with reason == discarded
scribe: we considered declarative API: came to conclusion that it'll be very complex to meet all the requirements; more info in explainer
todd: what's the best way to catchup with latest thinking?
shubhie: explainer is up to date -- review that
todd: on some platforms the OS state does not map exactly, we may have to account for that
... the other gotcha is that there is no limit on callbacks
... longtail (bad) examples are bad code on sites
... existing callbacks may limit our ability
<scribe> ACTION: Todd to review TTI and lifecycle