> > 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 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? 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.
