Hi, The API owners discussed this intent today. In addition to the above questions, we achieved consensus that if you were content with 1 minute instead of 10 seconds, we'd be prepared to LGTM. For 10 seconds, we have additional concerns that would require more discussion and caveats. If 1 minute achieves your goal of battery savings, could we go with that?
On Wed, Nov 16, 2022 at 5:15 PM Rick Byers <rby...@chromium.org> wrote: > Thinking some more about this, perhaps it really comes down to what the > nesting level >5 criteria means in practice? I guess metrics on how common > such tasks are won't be helpful because if they weren't common then it > wouldn't be attractive for power savings. But do you have anecdotal > experience suggesting that user-important events like Daniel and Philip are > worried about tend to be a lower nesting level, while things like analytics > and ads tracking tends to be higher nesting level? Any idea what data went > into the selection of "5" as the threshold? > > It looks like there are other important heuristics too, like timers > started in network response handlers aren't subject to throttling. This is > clearly pretty nuanced, not something I'd really trust our judgement to be > able to accurately evaluate the risk of. Rather than try to speculate on > heuristic details here, perhaps it would be more productive to try to align > on the principals for how you're evaluating compat risk? > > In particular, no issue at 50% beta and 1% stable seems like a pretty > strong signal to me (especially relative to prior tab freezing efforts). > But how confident are you in bugs reaching you? Eg. if a tester bisects > based on a customer provided repo, is it likely to point to a CL you > landed? Or does this being under finch control mean that a bisect won't > work to identify the cause of a regression? I just searched for any bug > opened in the last 180 days which mentions setTimeout and setInterval in > the summary and didn't find anything relevant, so that's IMHO a significant > data point in your favor. Also the example you cite from the previous > change looks like it was quickly routed to you, so a good sign. > > Note I think we avoid 100% trials in beta because that leaves the stable > config unvalidated, so topping out at 50% on beta seems right to me. But > what's the launch plan after that? Will you go straight to 100% stable and > consider backing back down if there are non-trivial reports of breakage? Or > do a gradual ramp? > > Reading through the prior example you cited, I suspect the randomness of > finch trials could cause some frustration here - eg. some customers > complaining of breakage but devs being unable to reproduce it. What would > you think about ramping down the timer value predictably rather than > gradually ramping up the finch trial? I.e. drop 100% of stable users from 5 > minutes to 2 minutes first? Perhaps a few weeks at 2 minutes, then 30 > seconds without issue would be enough to reduce fear of going to 10 seconds > while still giving predictability to developers trying to figure out what's > going on? > > Rick > > On Wed, Nov 16, 2022 at 12:13 PM Daniel Bratell <bratel...@gmail.com> > wrote: > >> Hi François, >> >> We [MikeT, Rick, Yoav, Chris and I] discussed this on the API Owners >> meeting and there were some things affecting user experience I was >> concerned about. >> >> Looking at the maximum perceived impact to the user, that would be that >> the user is putting a tab in the background, but expecting some kind of >> event in a couple of seconds. If that event depends on the throttled >> timers, that event could, worst case, with this change be delayed from 10 >> seconds to 1 minute (or 10 seconds + 1 minute?). Before this change, worst >> case would be that some event would be delayed from 5 minutes to 6 minutes. >> >> I consider, from a usage perspective, a delay from 5 to 6 minutes (worst >> case) acceptable if there are other benefits to the delay, but a change >> from 10 seconds to 1 minute (worst case) seems much more impactful since it >> would be fivefold increase in waiting time. >> >> Considering that, have you investigated if there is some kind of middle >> ground where a smaller change would get more or less the same benefit to >> battery life? Or is there some other more advanced gradual throttling that >> could make the worst case less bad? Or do you have data that shows that my >> concern is irrelevant in some way? >> >> /Daniel >> >> On 2022-11-11 17:56, François Doray wrote: >> >> We are experimenting on 1% stable since the beginning of October 2022 >> (M106+). We are also experimenting on 50% of Canary/Dev/Beta since June >> 2022. Enabling on 100% of Canary/Dev/Beta for a few milestones sgtm, if we >> think it will help identifying issues. So far, no bug reports have been >> routed to me. >> >> Note: Only timers with a "nesting level >> <https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timer-nesting-level>" >> greater than 5 are affected. A timer set from the visibilitychange event >> handler, for example, won't be affected. >> >> >> On Wed, Nov 9, 2022 at 12:02 PM Philip Jägenstedt <foo...@chromium.org> >> wrote: >> >>> The potential compat risk of this seems significant, if it means that >>> pages can start misbehaving or breaking after 10 seconds in the background, >>> which seems common in workflows like logins or ecommerce, where you might >>> be flipping back and forth between tabs to find passwords, confirm credit >>> card transactions, etc. >>> >>> Have there been any bug reports from the beta experiment yet? To >>> increase confidence, can we run this experiment at 100% on beta, dev and >>> canary for a few milestones before trying it on stable? Are there any other >>> ways we can gain insight on the compat risk? >>> >>> On Tue, Nov 8, 2022 at 10:10 PM François Doray <fdo...@chromium.org> >>> wrote: >>> >>>> Contact emails jiahe.zh...@intel.com, fdo...@chromium.org >>>> >>>> Specification >>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html >>>> >>>> Design docs >>>> >>>> https://docs.google.com/document/d/1WFyfKUUxqM7uKxKOGhLiOjyY6T7QRduVcuHN0f6vJkk/edit >>>> >>>> Summary >>>> >>>> Enter Intensive Wake Up Throttling after 10 seconds if the page is >>>> fully loaded when it becomes hidden. Currently, wake ups from JS timers >>>> with a nesting level >= 5 are throttled to 1 per minute after the page has >>>> spent 5 minutes in the background [1], which is very conservative and was >>>> chosen to allow a launch of Intensive Wake Up Throttling with minimal >>>> regression risk. We're now planning to reduce this timeout to 10 seconds if >>>> the page is fully loaded when hidden. [1] >>>> https://chromestatus.com/feature/4718288976216064 >>>> >>>> >>>> Blink component Blink>Scheduling >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling> >>>> >>>> TAG review status Not applicable >>>> >>>> Risks >>>> >>>> Interoperability and Compatibility >>>> *Gecko*: No signal >>>> >>>> *WebKit*: No signal >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: The more conservative version of Intensive Wake Up >>>> Throttling shipped smoothly to 100% Stable more than 1 year ago. A few bugs >>>> were filed, but in all cases we've been able to propose workarounds which >>>> made apps more efficient (example >>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1186569#c16>). >>>> >>>> WebView application risks >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> >>>> >>>> No, this feature will not ship on desktop platforms. >>>> >>>> >>>> Debuggability >>>> >>>> This is not a new Web Platform feature. >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, Chrome OS, Android, and Android WebView)? No >>>> >>>> This feature will only ship on desktop platforms. On Android, the >>>> system severely limits resource consumption in background renderers, which >>>> makes this feature unnecessary. >>>> >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? Yes >>>> >>>> Flag name quick-intensive-throttling-after-loading >>>> >>>> Requires code in //chrome? False >>>> >>>> Tracking bug >>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1324656 >>>> >>>> Estimated milestones >>>> DevTrial on desktop >>>> >>>> Enabled by default on desktop 104 >>>> >>>> 109 >>>> Anticipated spec changes >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5580139453743104 >>>> >>>> *Additional context* >>>> >>>> The 1% stable experiment shows that this feature reduces Chrome's CPU >>>> usage and extends battery life, as desired. We plan to enable it by default >>>> in M109. >>>> >>>> The 1% stable experiment is still ramping up, so we would like to keep >>>> experimenting in M108, to get small confidence intervals for all our >>>> metrics on all desktop platforms. >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5EGWuOZgo1k5XExKpnjsRM9nacEeFMyiXkEOwW%3DkOqRUQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5EGWuOZgo1k5XExKpnjsRM9nacEeFMyiXkEOwW%3DkOqRUQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5Fy3FRsxTwde26%3DincDr7PR%2Bz4VKowfikMkPgSxxLhScA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5Fy3FRsxTwde26%3DincDr7PR%2Bz4VKowfikMkPgSxxLhScA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e54c5cf-72be-500f-c3d3-a1cf00514447%40gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e54c5cf-72be-500f-c3d3-a1cf00514447%40gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-Kvf6341Fbyi1ggxrKDTPfrSXcfVP_9FG%2Bmk%2BKbO2ZjA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-Kvf6341Fbyi1ggxrKDTPfrSXcfVP_9FG%2Bmk%2BKbO2ZjA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_KXrEKvAcoyHNmhMh6jhOabe3DSWEj8SyRKMyWJ_auZQ%40mail.gmail.com.
