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/270fd347-17a4-4601-9715-ef6f9fe6b4a9n%40chromium.org.
