Intent to Ship: Remove clamping of setTimeout(...) to >= 1ms

[Chromestatus]

Contact emails

chri...@chromium.org

Explainer

None

Specification

None

Summary

Currently setInterval with a value less than 1 is clamped to 1. This intent removes that restriction. Before: setInterval(..., 0) -> 1ms delay. After: setInterval(..., 0) -> 0ms delay. Notes: * This has no effect on the 4ms clamping for nested calls to timeouts. * setTimeout clamping was removed in a previous intent.

Blink component

Blink>Scheduling>APIs

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Firefox already does not clamp setInterval to 1ms. Chromium-based browsers have not clamped setTimeout since 2022: https://groups.google.com/a/chromium.org/g/blink-dev/c/HKPTp7C1LwY/m/I0pm-cqFAQAJ Webkit removed clamping of setTimeout: https://bugs.webkit.org/show_bug.cgi?id=221124 Webkit still has clamping for setInterval: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L54 Bug requesting removal of that: https://bugs.webkit.org/show_bug.cgi?id=286774

Gecko: Shipped/Shipping

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?

No special risks for WebView.

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Availability expectation

Available on Chromium-based and Gecko-based browsers.

Adoption expectation

N/A

Adoption plan

N/A

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop	135
Shipping on Android	135
Shipping on WebView	135

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5072451480059904?gate=5191183770583040

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

(fixed intent title)

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/679c0447.2b0a0220.243291.046c.GAE%40google.com.

[Stephen Chenney]

On Thu, Jan 30, 2025 at 6:00 PM Chris Harrelson <chri...@chromium.org> wrote:

(fixed intent title)

On Thu, Jan 30, 2025 at 2:59 PM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

chri...@chromium.org

Explainer

None

Specification

None

Summary

Currently setInterval with a value less than 1 is clamped to 1. This intent removes that restriction. Before: setInterval(..., 0) -> 1ms delay. After: setInterval(..., 0) -> 0ms delay. Notes: * This has no effect on the 4ms clamping for nested calls to timeouts. * setTimeout clamping was removed in a previous intent.

What are the semantics of setInterval(..., 0)? Is it "run on every frame", like repeated rAF()? Does it also run immediately in the current frame? Something else?

Is there any spec that answers questions about the setInterval(0) behavior?

Stephen.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9ed3LWdydDUohaatss9EDhJAMNdjgT%2BUuzQ04LKazu0A%40mail.gmail.com.

[Chris Harrelson]

On Thu, Jan 30, 2025 at 6:13 PM Stephen Chenney <sche...@chromium.org> wrote:

On Thu, Jan 30, 2025 at 6:00 PM Chris Harrelson <chri...@chromium.org> wrote:

(fixed intent title)

On Thu, Jan 30, 2025 at 2:59 PM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

chri...@chromium.org

Explainer

None

Specification

None

Summary

Currently setInterval with a value less than 1 is clamped to 1. This intent removes that restriction. Before: setInterval(..., 0) -> 1ms delay. After: setInterval(..., 0) -> 0ms delay. Notes: * This has no effect on the 4ms clamping for nested calls to timeouts. * setTimeout clamping was removed in a previous intent.

What are the semantics of setInterval(..., 0)? Is it "run on every frame", like repeated rAF()? Does it also run immediately in the current frame? Something else?

It means "keep running it constantly without delay" via sequential tasks. But other event loop tasks may intervene if the browser chooses to run them.m

 

Is there any spec that answers questions about the setInterval(0) behavior?

https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-setinterval-dev

0 is not special-cased in setInterval.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQGVnbwAZDMnMygGxxV%3Da0njj9ooBae4YoQsws38fhRBQ%40mail.gmail.com.

[Domenic Denicola]

This looks generally good; just a few requests.

Given that setInterval is more rare than setTimeout, and we successfully fixed this for setTimeout, and Firefox already has this behavior, I'm optimistic this won't be a compat problem.

On Fri, Jan 31, 2025 at 8:00 AM Chris Harrelson <chri...@chromium.org> wrote:

(fixed intent title)

On Thu, Jan 30, 2025 at 2:59 PM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

chri...@chromium.org

Explainer

None

Specification

None

Might be worth pointing to https://html.spec.whatwg.org/#dom-setinterval . The spec sort of allows either behavior in https://html.spec.whatwg.org/#run-steps-after-a-timeout step 4.3, but I think step 4.2 makes our current implementation observably incorrect. (See below note about WPTs.)

 

Summary

Currently setInterval with a value less than 1 is clamped to 1. This intent removes that restriction. Before: setInterval(..., 0) -> 1ms delay. After: setInterval(..., 0) -> 0ms delay. Notes: * This has no effect on the 4ms clamping for nested calls to timeouts. * setTimeout clamping was removed in a previous intent.

Blink component

Blink>Scheduling>APIs

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Firefox already does not clamp setInterval to 1ms. Chromium-based browsers have not clamped setTimeout since 2022: https://groups.google.com/a/chromium.org/g/blink-dev/c/HKPTp7C1LwY/m/I0pm-cqFAQAJ Webkit removed clamping of setTimeout: https://bugs.webkit.org/show_bug.cgi?id=221124 Webkit still has clamping for setInterval: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L54 Bug requesting removal of that: https://bugs.webkit.org/show_bug.cgi?id=286774

Gecko: Shipped/Shipping

WebKit: No signal

Web developers: No signals

I'm just curious, have any web developers complained about this, or is this mostly done out of a desire for interop, or...?

 

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?

No special risks for WebView.

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

No

This seems to be testable by checking the relative ordering of setTimeout(f,0) and setInterval(g,0), with a test like https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=13477 . Maybe you could add one?

 

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

A Finch flag seems important for this, just in case it causes compat issues.

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9ed3LWdydDUohaatss9EDhJAMNdjgT%2BUuzQ04LKazu0A%40mail.gmail.com.

[Chris Harrelson]

On Tue, Feb 4, 2025 at 6:33 PM Domenic Denicola <dom...@chromium.org> wrote: 

Is this feature fully tested by web-platform-tests?

No

This seems to be testable by checking the relative ordering of setTimeout(f,0) and setInterval(g,0), with a test like https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=13477 . Maybe you could add one?

Good point. I added a test here. I noted it in the chromestatus entry as well.

 justification

None

A Finch flag seems important for this, just in case it causes compat issues.

There is a finch flag (SetIntervalWithoutClamp), my mistake. Edited chromestatus. 

[Domenic Denicola]

LGTM1. I'm still curious on the web developer signals, if you have anything to share there :)

>> Web developers: No signals

>

> I'm just curious, have any web developers complained about this, or is this mostly done out of a desire for interop, or...?

[Yoav Weiss (@Shopify)]

LGTM2

[Rick Byers]

LGTM3

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2842e492-ead5-49ab-b02a-62a7c85dd46bn%40chromium.org.