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.
