On Wed, Aug 3, 2022 at 7:07 PM Etienne Pierre-doray <etien...@chromium.org> wrote:
> What's the plan for monitoring potential breakage? Looking at incoming >> bugs? > > Yes, there's been a few breakage on earlier channel (all addressed as of > now). This one was related to DOM timer: > https://buganizer.corp.google.com/issues/220682826 > For folks outside of Google, the bug describes a site that relied on timer accuracy to schedule tasks, and saw a degradation in their performance metrics. The site in question then fixed it by moving away from those methods. (I hope I'm capturing that correctly. I only skimmed through the issue so please correct me if I got it wrong) I suspect many non-Google properties run similar code, and would similarly be surprised by this change. e.g. I know that many JS driven animations used to rely on timers, and I'm not sure that's no longer the case. Similarly, performance measurements that rely on timer accuracy as a proxy for "CPU busyness" are common. > Might be worthwhile to ask: https://bit.ly/blink-signals > > There's anecdotal evidence that Webkit is aligning timers at 10ms; all I > could find re. DOM timers is this > <https://sourcegraph.com/github.com/WebKit/WebKit/-/commit/9583464b465af2976839791deff41cbe6495f6ca?visible=6> > throttling > at 30Hz in low power mode. > Does https://bit.ly/blink-signals apply even if this chromestatus doesn't > change the spec? > The web-exposed behavior is changing here, with potential compatibility and interoperability implications. So even if the spec allows for that, I think it's worthwhile to ask other vendors for their opinions on this. > > Question: What about APIs that have no proper flow control support, e.g. >> WebSocket? They rely on (ab)use of setTimeout to avoid writing too much >> into the underlying buffer. I wouldn't consider a 1s flow disruption delay >> to be acceptable for this use case, not even in the background. Are there >> any plans to prevent such issues? >> > Although that was meant for another proposal, this blog post > <https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds> > suggests an alternative to some setTimeout abuses. > Note that this proposal only concerns the 8ms delay. The 1s throttling was > done in this previous chromestatus > <https://chromestatus.com/feature/4718288976216064> for background pages > and shipped in M86. > > On Wed, Aug 3, 2022 at 11:42 AM Lennart Grahl <lennart.gr...@gmail.com> > wrote: > >> Question: What about APIs that have no proper flow control support, e.g. >> WebSocket? They rely on (ab)use of setTimeout to avoid writing too much >> into the underlying buffer. I wouldn't consider a 1s flow disruption delay >> to be acceptable for this use case, not even in the background. Are there >> any plans to prevent such issues? >> >> On Wednesday, 3 August 2022 at 15:50:48 UTC+2 Etienne Pierre-doray wrote: >> >>> etie...@chromium.org >>> >>> ExplainerNone >>> >>> Specification >>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html >>> >>> Design docs >>> >>> https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit >>> >>> Summary >>> >>> Run all timers (with a few exceptions) with a non-zero delay on a >>> regular 8ms aligned wake up (125 Hz), instead of as soon as their delay has >>> passed. This affect DOM timers; On foreground pages, run DOM timers with a >>> non-zero delay on a regular 8ms aligned wake up, instead of as soon as >>> their delay has passed. On background pages, DOM timers already run on a >>> regular 1s aligned wake up (1 Hz), or even less frequently after 5 minutes. >>> >>> >>> Blink componentBlink>Scheduling >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling> >>> >>> TAG review >>> >>> TAG review statusNot applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> This feature changes the behavior of an existing API in a way that is >>> spec-compliant (the spec says "Optionally, wait a further >>> implementation-defined length of time", ref.: >>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout). >>> Content that relies on precise timing for DOM Timers may stop working >>> properly in Chromium with this feature. The risk is mitigated by delaying >>> DOM Timers by at most 8 ms, and by disabling the feature when WebRTC has >>> active connections in the process. Content that cannot support a 8 ms delay >>> would probably be better served by alternative APIs described at >>> https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds. >>> Due to the significant battery savings that come with this feature, we >>> expect that most browsers will decide to implement it after some time. >>> >>> >>> *Gecko*: No signal >>> >>> *WebKit*: No signal >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> 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? >>> >>> >>> >>> Goals for experimentation >>> >>> Gain insight on potential compatibility issues and evaluate impact on >>> guardian metrics (page load, latency). >>> >>> >>> Reason this experiment is being extended >>> >>> >>> >>> Ongoing technical constraints >>> >>> >>> >>> Debuggability >>> >>> This changes the behavior of an existing API. No new debugging support >>> is added. >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)?Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?No >>> >>> DevTrial instructions >>> https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md >>> >>> Flag namealign-wakeups >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://crbug.com/1153139 >>> >>> Estimated milestones >>> OriginTrial desktop last 105 >>> OriginTrial desktop first 105 >>> DevTrial on desktop 105 >>> OriginTrial Android last 105 >>> OriginTrial Android first 105 >>> DevTrial on Android 105 >>> OriginTrial webView last 105 >>> OriginTrial webView first 105We plan to do a 1% Stable experiment for >>> M105 stable. >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5680188671655936 >>> >> -- > 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/CALoDvsZoosJps02cN-3885ubOggjk_JkH4ffUZosQoTWFrNWuQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsZoosJps02cN-3885ubOggjk_JkH4ffUZosQoTWFrNWuQ%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/CAL5BFfU2_t3oAHuSsnJvEnO3SPs%3DecM-PU%2BW0YM23eYA-kaGOw%40mail.gmail.com.
