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 <chris...@chromium.org> wrote: > (fixed intent title) > > On Thu, Jan 30, 2025 at 2:59 PM Chromestatus < > ad...@cr-status.appspotmail.com> wrote: > >> Contact emails chris...@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 >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EScheduling%3EAPIs%22> >> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? 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. > >> >> 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 >> <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 blink-dev+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/679c0447.2b0a0220.243291.046c.GAE%40google.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9ed3LWdydDUohaatss9EDhJAMNdjgT%2BUuzQ04LKazu0A%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9ed3LWdydDUohaatss9EDhJAMNdjgT%2BUuzQ04LKazu0A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8_1Fj7k%2BjaGdQQ8j%2B3b-miG2tNkimrYkodSsnPwKwLNA%40mail.gmail.com.
