LGTM3 On Wednesday, March 1, 2023 at 8:34:52 AM UTC-8 Yoav Weiss wrote:
> 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/e56b6f93-ed15-4923-87df-d3af59be684an%40chromium.org.
