Bug 221124 – Not clamp setTimeout(..., 0) to 1ms

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Wanming Lin]

Calls to setTimeout(..., 0) is clamped to a 1 ms timeout in WebKit(https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L384), this is actually a bug since there's no 1ms clamp in the spec(https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timer-initialisation-steps), and which will cause scheduling error, e.g.

setTimeout(()=> console.log('1ms timeout'), 1);
setTimeout(()=> console.log('0ms timeout'), 0);

Outputs:
Safari:  1ms timeout, 0ms timeout

Moreover, 1ms clamp may bring performance penalty.

Compatibility:
Firefox: no 1ms clamp
Safari: 1ms clamp
Chrome: 1ms clamp

Chrome is planning to remove this 1ms clamp, see discussion at https://groups.google.com/a/chromium.org/g/blink-dev/c/HKPTp7C1LwY/m/kIbTxKSPAwAJ

[Alexey Proskuryakov]

What is the motivation for changing the behavior, as opposed to correcting the spec? Seems like only bad things can possibly happen with regards to battery life; and there are other reasons why timers would be clamped anyway (nesters timers, backgrounds tabs).

If this is desired to correct ordering, there are other ways to do it, but also unsure if it's a particularly likely case to run into.

[Wanming Lin]

Thanks Alexey! One more motivation of this change is performance impact, we can see about 1% beneficial to Speedometer 2 on MiniBrowser on M1 with this change.

[Radar WebKit Bug Importer]

<rdar://problem/73852354>

[Ryosuke Niwa]

As far as we've tested, there were no improvements on Intel Macs.

[Cameron McCormack (:heycam)]

Removing the 1ms setTimeout minimum, and leaving the existing nested throttling behavior, currently shows a 1.7% improvement on Speedometer locally for me, on an M1 MacBook Air.

[Cameron McCormack (:heycam)]

And 1.2% on my Intel MBP.

[Cameron McCormack (:heycam)]

Created attachment 454760 [details]
Patch

[EWS Watchlist]

This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see https://trac.webkit.org/wiki/WPTExportProcess

[Cameron McCormack (:heycam)]

Created attachment 455027 [details]
Patch

[EWS]

Committed r291476 (248592@main): <https://commits.webkit.org/248592@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 455027 [details].

[WebKit Commit Bot]

Re-opened since this is blocked by bug 238098

[Ryan Haddad]

Saw some setTimeout test flakiness after this change:

https://results.webkit.org/?suite=layout-tests&suite=layout-tests&suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fworkers%2Finterfaces%2FWorkerUtils%2FimportScripts%2Freport-error-setTimeout-cross-origin.sub.any.worker.html&test=imported%2Fw3c%2Fweb-platform-tests%2Fworkers%2Finterfaces%2FWorkerUtils%2FimportScripts%2Freport-error-setTimeout-redirect-to-cross-origin.sub.any.worker.html&test=imported%2Fw3c%2Fweb-platform-tests%2Fworkers%2Finterfaces%2FWorkerUtils%2FimportScripts%2Freport-error-setTimeout-same-origin.sub.any.worker.html

[Cameron McCormack (:heycam)]

I shouldn't have cq+ed this last night.

Thinking about that test failure more this morning, I'm wondering if setTimeout(..., 0) callbacks are preempting whatever else is in the event queue.  The HTML spec says that when the timeout fires, it should post a task to the event queue to run the timeout callback.

[Cameron McCormack (:heycam)]

Created attachment 455210 [details]
Patch v2

[Cameron McCormack (:heycam)]

Created attachment 455212 [details]
Patch v2.1

[Cameron McCormack (:heycam)]

Created attachment 455550 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 455868 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 455880 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 455881 [details]
Patch

[EWS]

Committed r291998 (248952@main): <https://commits.webkit.org/248952@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 455881 [details].