Thanks Etienne.
LGTM1 to ship - good luck with the rollout.
On 10/20/22 12:18 PM, Etienne Pierre-doray wrote:
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 <miketa...@chromium.org>
wrote:
On 10/19/22 8:05 PM, Etienne Pierre-doray wrote:
Contact emails
etien...@chromium.org
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
<http://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 blink-dev+unsubscr...@chromium.org.
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/18082bde-90c1-1f9c-5652-80857ff9e983%40chromium.org.
