Hi API owners, I agree that using a 1 minute grace period (instead of 10 seconds) is less risky and will likely yield similar resource savings. We'll experiment with this new grace period and keep you updated with the results.
Side note: Chains of timers on background pages can usually be replaced with more resource-efficient APIs, see https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds. We think it would be a good thing if, for example, Web content migrated from polling a server to push Web Sockets in response to tighter restrictions on timers. More details below. Have a nice day, François On Wed, Nov 23, 2022 at 12:03 PM Chris Harrelson <chris...@chromium.org> wrote: > 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? > Yes we could. > > 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? >> > For many years, the spec has said that the timeout of a timer with a nesting level >5 is clamped to be >= 4ms. https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers We used the same criteria to apply intensive throttling. > >> 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. >> > I admit that we don't have a perfect process to ensure that bugs are routed to us. If someone experiences a problem, they could manually disable features enabled via Finch (listed at chrome://version/?show-variations-cmd). If they filed a bug with the experiment name (QuickIntensiveWakeUpThrottlingAfterLoading), we would find it. But I'm not convinced that most people would do this. We should probably include clear debug steps in release notes? > >> 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? >> > We definitely want a 1% stable experiment to confirm that this change has a positive impact. Ramping up to 50% stable gives us more confidence in the results, but going straight to 100% stable to reduce variations between Chrome clients also works. > >> 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? >> > Gradually reducing the grace period for 100% of stable wouldn't let us confirm that the intervention has a positive impact. What do you think of experimenting with the target grace period for 1% stable to confirm impact, and then launching by gradually reducing the grace period for 100% of stable until we reach the target? > >> 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/CAGD3t5EyfGW-4Buui93A43zZZvF7Z832JKw58vqSd-bz9f-%2BLQ%40mail.gmail.com.
