> > Have we asked Mozilla for a signal? I haven't asked for a signal. I can ask but this feels N/A; this change is Web facing but remains spec-compliant, and I don't think we want to change the spec or browsers need to align. Quoting a reply from Webkit "even if there were a web specification, and even if a browser faithfully tried to implement it, the web programmer would still not get the specified behavior on most hardware and operating systems most of the time." I should correct myself, asking for a position form WebKit actually yielded an invalid signal "The issue is not about a specification".
On Thu, Oct 20, 2022 at 11:23 AM Mike Taylor <[email protected]> wrote: > On 10/19/22 8:05 PM, Etienne Pierre-doray wrote: > > Contact emails [email protected] > > Specification > https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html > > Design docs > > https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit > > Summary > > Run all timers (with a few exceptions) with a non-zero delay on a regular > 8ms aligned wake up (125 Hz), instead of as soon as their delay has passed. > This affects DOM timers; On foreground pages, run DOM timers with a > non-zero delay on a regular 8ms aligned wake up, instead of as soon as > their delay has passed. On background pages, DOM timers already run on a > regular 1s aligned wake up (1 Hz), or even less frequently after 5 minutes. > > > Blink component Blink>Scheduling > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling> > > TAG review > > TAG review status Not applicable > > Risks > > > Interoperability and Compatibility > > This feature changes the behavior of an existing API in a way that is > spec-compliant (the spec says "Optionally, wait a further > implementation-defined length of time", ref.: > https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout). > Content that relies on precise timing for DOM Timers may stop working > properly in Chromium with this feature. The risk is mitigated by delaying > DOM Timers by at most 8 ms. Content that cannot support a 8 ms delay would > probably be better served by alternative APIs described at > https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds. > Due to the significant battery savings that come with this feature, we > expect that most browsers will decide to implement it after some time. > > > *Gecko*: No signal > > Have we asked Mozilla for a signal? > > > *WebKit*: Neutral (https://github.com/WebKit/standards-positions/issues/44) > Note that WebKit already has some DOM timer alignment logic (see > Page::updateDOMTimerAlignmentInterval()), which depends on low power mode, > page visibility and user interaction. It's also possible that there's some > alignment logic at the platform level which is designed to reduce CPU > wakeups. > > *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? > > > Debuggability > > This changes the behavior of an existing API. No new debugging support is > added. > > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? No > > DevTrial instructions > https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md > > Flag name align-wakeups > > Requires code in //chrome? False > > Tracking bug https://crbug.com/1153139 > > > Estimated milestones > DevTrial on desktop 105 > DevTrial on Android 105 > Chrome on desktop 107 > Chrome on Android 107 > > 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). > This feature changes the behavior of an existing API in a way that is > spec-compliant > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5680188671655936 > > Links to previous Intent discussions Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/calodvsaqa8iqxdxneh1pkbczpfssssmz72jgmev-bdweng6...@mail.gmail.com> > > Related to this discussion > <https://groups.google.com/a/chromium.org/g/blink-dev/c/POCUbyCqnrc/m/MfPXQmm8AgAJ>; > we're > now at step (3), the feature has been enabled at 100% on beta for almost 3 > weeks, and M107 will soon roll out to stable. > Enabling the feature by default triggered crbug.com/1368989 (fuschia > only, addressed), although this was unrelated to the web platform and DOM > timers. No other issues were reported AFAIK. > > > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsbKunY1%3DzbQ38HxKa3kyEvZjNB4ekqZLGmyYsM0uQPB1w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsbKunY1%3DzbQ38HxKa3kyEvZjNB4ekqZLGmyYsM0uQPB1w%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsa_pB58FW8zB%2B-Bii0iC7ZNK-Py5qQ%2B4aRTcyAPh-ij2g%40mail.gmail.com.
