LGTM to experiment M101-102 inclusive Thanks for working on this!! What's the plan for finding sites this breaks? Monitor bug reports? Or is there something more proactive we could do?
On Monday, March 28, 2022 at 9:36:30 PM UTC+2 Etienne Pierre-doray wrote: > 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: 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). > > > > 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 102 > OriginTrial desktop first 101 > DevTrial on desktop 101 > OriginTrial android last 102 > OriginTrial android first 101 > DevTrial on android 101 > > Targeting Beta 50% for at least 8 weeks for more chance of teasing out > breakage. I'll send a follow-up with what we learn prior to experimenting > on 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 > > > 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/6c90e56e-c49b-41f2-8203-0f349f109c32n%40chromium.org.
