This intent was the subject of a long discussion at API OWNERS today, and I'm wondering if we understand the constituent test in Speedometer (or the harness) that is favouring Safari's out-of-spec behaviour?
Speedometer seems like the key motivator here, rather than public content, and winning it matters in the interim while Apple is gaming this for the purposes of benchmarketing. I'd support finching this on for Stable for some releases while we get resolution on fixing the benchmark. Best, Alex On Thursday, October 13, 2022 at 1:00:12 PM UTC-7 Etienne Pierre-doray wrote: > Contact emailsetien...@chromium.org > > 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 15. 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? > > > > 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)?No > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?No > > Flag nameunthrottled-nested-timeout > > Requires code in //chrome?False > > Tracking bughttps://crbug.com/1108877 > > Launch bughttps://launch.corp.google.com/launch/4201069 > > Estimated milestones > Chrome for desktop: 108 > Chrome for Android: 108 > Android Webview 108 > > Anticipated spec changesThe spec dictates a nesting threshold of 5 > https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html "If > nesting level is greater than 5, and timeout is less than 4, then set > timeout to 4." Chrome has never respected the exact behavior ( > crbug.com/1108877), and safari recently updated the threshold to 10 ( > https://github.com/WebKit/WebKit/commit/786e3e0b252e38fb01c8db97a94d52cb0f57891e). > > A potential change to the spec is to make the threshold "implementation > dependent" to match reality. > > 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 > Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsZNwh5uBANxryWHCdgFVFCts6noKSU9FY1BcqYH0%3D55sg%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsZNwh5uBANxryWHCdgFVFCts6noKSU9FY1BcqYH0=5...@mail.gmail.com> > Intent to Extend Experiment: > https://mail.google.com/mail/u/0/#search/in%3Asent+settimeout/KtbxLzGLjTQPrFFjRfPrfQCtcCmwvTksJV > > <https://mail.google.com/mail/u/0/#search/in:sent+settimeout/KtbxLzGLjTQPrFFjRfPrfQCtcCmwvTksJV> > > This was previously enabled through field-trial on Beta 50% and Stable 1% > on M104-105, with a more aggressive nesting threshold = 100. No breakage > was reported, but it showed small guiding metrics (startup) regressions on > Android. I'm confident that having a lower threshold will eliminate the > adverse effects. Ideally, I would conduct another round of field-trial, but > I think we're better off with doing a waterfall roll-out, and experiment > later on (1% stable) to confirm no regressions: > > - Gradually rolling-out to each channel at 100% has more chances of > teasing out potential brokerage and won't be perceived as flaky failures. > I > will loop back after 100% beta before we hit stable. > - This will involve fewer back and forth with blink-dev / API owners, > and allow us to benefit from performance gains sooner. > > > > > 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/53c3ba4d-1899-49ff-a351-0686869d967an%40chromium.org.
