Contact [email protected] ExplainerNone
Specification https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html Design docs https://docs.google.com/document/d/1boT0k8BQjl7mXXzvI9SdN4XJPSza27vE8T0CNxmMhCI Summary Increase the nesting threshold before which setTimeout(..., <4ms) start being clamped, from 5 to 100. setTimeout(..., 0) is commonly used to break down long Javascript tasks and let other internal tasks run, which prevents the browser from hanging. setTimeouts and setIntervals with an interval < 4ms are not clamped as aggressively as they were before. This improves short horizon performance, but websites abusing the API will still eventually have their set setTimeouts clamped Blink componentBlink <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> TAG review TAG review statusNot applicable Risks Interoperability and Compatibility setTimeout is a well established and mature API. This change poses a risk of breaking websites and tests that rely on the current timing caused by clamping and the subtle task ordering that it entails. As an example, this change breaks assumptions about the ordering between setTimeout(0) and unrelated tasks in at least one case in Chrome tests (crbug.com/1302309). On the flip side, the implementation in Chrome is already non compliant ( crbug.com/1108877). There's also a similar experiment on beta that is ongoing (crbug.com/1263190). Devs can use chrome://flags#unthrottled-nested-timeout to test their sites for compatibility issues. Gecko: No signal WebKit: Shipped/Shipping <https://sourcegraph.com/github.com/WebKit/WebKit/-/commit/786e3e0b252e38fb01c8db97a94d52cb0f57891e> 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 Our goals are to determine the extent of breakage caused by this feature to determine if it is safe to ship and to ensure we performance metrics don't regress, e.g. core web vitals. We've previously experimented at 50% on Canary/Dev/Beta without capturing any issues, and we would like to experiment on Stable to analyze the impact on the broader population. Ongoing technical constraints None Debuggability setTimeout() and setInterval() have an associated trace event in DevTools. https://developer.chrome.com/docs/devtools/evaluate-performance/performance-reference/ 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/+/master/docs/testing/web_platform_tests.md> ?No Flag nameunthrottled-nested-timeout Requires code in //chrome?False Tracking bughttps://crbug.com/1108877 Estimated milestones OriginTrial desktop last 105 OriginTrial desktop first 104 DevTrial on desktop 101 OriginTrial android last 105 OriginTrial android first 104 DevTrial on android 101 We plan to do a 1% Stable experiment for M104 and M105 stable. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5710690097561600 Links to previous Intent discussionsReady for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/-TjeYs7shTQ/m/FhJq0mQyDAAJ I2E on Beta: https://groups.google.com/a/chromium.org/g/blink-dev/c/iT0CpRXs4TE/m/iAxA4RcuAQAJ This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsZEct_0U%2B-p8cpvfT3ENFnCkg2tKa-5OTp1LTBLGcNKAg%40mail.gmail.com.
