Ready for Trial: Increased max nesting level for setTimeout(0)

[Etienne Pierre-doray]

Contact emails

etie...@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 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 component

Blink

TAG review

TAG review status

Not 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 clamping behavior and the subtle task ordering that it entails. As an example, this change breaks the assumption that setTimeout(0) causes micro tasks to run 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:

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?

No

Flag name

unthrottled-nested-timeout

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1108877

Estimated milestones

DevTrial on desktop

101

DevTrial on android

101

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5710690097561600

This intent message was generated by Chrome Platform Status.

[Anne van Kesteren]

On Wed, Mar 9, 2022 at 8:16 PM Etienne Pierre-doray
<etie...@chromium.org> wrote:
> As an example, this change breaks the assumption that setTimeout(0) causes micro tasks to run in at least one case in Chrome tests (crbug.com/1302309).

This is something you plan to fix, right? setTimeout no longer
adhering to task semantics seems egregious.

[Scott Haseley]

On Fri, Mar 11, 2022 at 2:15 AM Ht Millican <haroldmil...@gmail.com> wrote:

I don't know maybe  just need some incentive  tired of the short end of the stick I mean all the time and effort  u guys put u can't do it 

This proposal doesn't change task semantics or when microtask checkpoints run, only the nesting level at which the 4ms clamping starts. I think this is a timing issue with that particular test; it looks like it’s depending on the relative order of setTimeouts and stream writer promise resolution, and changing when we clamp setTimeout affects that order. We'll look into the test and fix the ordering assumptions if they're invalid.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78jSSZuZTNnQ1me83xUD7XO82PKS4btmPKBGCkkqukxh_Q%40mail.gmail.com.

[Ht Millican]

I don't know maybe  just need some incentive  tired of the short end of the stick I mean all the time and effort  u guys put u can't do it 

On Fri, Mar 11, 2022, 3:53 AM Anne van Kesteren <ann...@annevk.nl> wrote: