LGTM2 On Wed, Mar 1, 2023 at 5:34 PM Chris Harrelson <chris...@chromium.org> wrote:
> LGTM1 to ship. The API owners met today and it's fine to run a 50% > experiment as part of the rollout. Thanks for the detailed work! > > On Tue, Feb 28, 2023 at 7:32 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> Thanks François for getting back to us, and I'm glad to hear we see >> meaningful improvements with the 1 minute throttle. >> From a web compat perspective, this *shouldn't* be highly observable, so >> assuming you haven't gotten bug reports or saw an uptick in some other >> metrics that can indicate this is causing an issue for backgrounded pages, >> I think it's fine to experiment with this for a larger population set, to >> get more meaningful results. >> >> In terms of the Blink process though, I'm not 100% sure what we want to >> do here, given that this is an intent to ship. Maybe best to send an intent >> to experiment with the exact experiment details you want to run. Would that >> be too much overhead? >> >> On Mon, Feb 27, 2023 at 8:24 PM 'François Doray' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> Hi blink-dev@! >>> >>> We experimented with the "Intensive Wake Up Throttling of Javascript >>> Timers after 1 minute in Background" feature on Stable 1%. With 7 days of >>> ramped up data, we observe small but statistically significant changes to >>> CPU usage. In addition to these savings, this feature encourages Web >>> developers to replace usage of Javascript timers with more efficient >>> APIs >>> <https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds> >>> . >>> >>> Could we ramp up the experiment to 50% of stable to measure the savings >>> with smaller confidence intervals? In particular, we don't expect to be >>> able to capture battery life improvements with 1% of stable. >>> >>> Thanks, >>> >>> Francois >>> On Monday, December 5, 2022 at 11:28:25 AM UTC-5 François Doray wrote: >>> >>>> 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 <chri...@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 <brat...@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...@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+...@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+...@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+...@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+...@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/514eef7d-5c70-4da1-a8fb-d892f3b5e1aan%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/514eef7d-5c70-4da1-a8fb-d892f3b5e1aan%40chromium.org?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/CAL5BFfUhYHKBk9nMJs7dCORDP_NZPEabrnxUe42emDJhrmkixA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUhYHKBk9nMJs7dCORDP_NZPEabrnxUe42emDJhrmkixA%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/CAL5BFfXwNs7YUS4gYDYh7-KijKxiHdQVaiDL5h8u9exvPSgB7Q%40mail.gmail.com.