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);
Safari: 1ms timeout, 0ms timeout
Moreover, 1ms clamp may bring performance penalty.
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
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.
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.
As far as we've tested, there were no improvements on Intel Macs.