Do I understand correctly that you're asking for experimentation only in
the 105?
We discussed this intent at the API owners meeting yesterday (Daniel, Rego,
MikeT and myself), and reached a conclusion that there are two goals for
this experiment, but only one of them can be achieved with 1% stable
experimentation.
We believe the experiment can show the potential benefits of such a
behavior change, but won't necessarily expose compat issues for sites that
don't pay very close attention (as it's easy to dismiss bugs in 1% of users
as flakes).
Hence, we think it's fine to run the experiment in order to figure out the
potential benefits, but would need a more elaborate plan to figure out the
compat implications and feasibility of shipping this.
Does that make sense?
On Fri, Aug 5, 2022 at 8:17 PM Stefan Zager <sza...@chromium.org> wrote:
> On Fri, Aug 5, 2022 at 11:00 AM Dave Tapuska <dtapu...@chromium.org>
> wrote:
>
>> Stefan, this was just for "non-zero delay" timers? Are there still
>> potential issues there?
>>
>
> Ah, sorry, I missed that detail. In that case, I think none of my
> objections apply.
>
>
>>
>> On Fri, Aug 5, 2022 at 1:19 PM Stefan Zager <sza...@chromium.org> wrote:
>>
>>> This is a common programming pattern:
>>>
>>> requestAnimationFrame(() => {
>>> setTimeout(() => {
>>> // At this point, it's very likely that layout is clean,
>>> // because we *just* completed a rendering update.
>>> // Queries of layout information are very unlikely to
>>> // trigger a forced layout.
>>> document.body.offsetTop;
>>> });
>>> });
>>>
>>> Aligning timers will make this strategy for avoiding forced layout less
>>> effective, because other non-timer tasks may run ahead of the setTimeout
>>> and invalidate layout.
>>>
>>> Also: the rAF(setTimeout()) construct is used extensively in chromium's
>>> test corpus, to schedule work ASAP after a rendering update. Many of our
>>> tests use a synchronous compositor: rendering updates happen without delay
>>> whenever there are no other tasks ready to run. In other tests, we increase
>>> the frequency of rendering updates from 60Hz to 200Hz, just because we know
>>> there won't be any long-running tasks and we want the tests to run faster.
>>>
>>> So... I see potential issues here.
>>>
>>> On Wed, Aug 3, 2022 at 6:50 AM Etienne Pierre-doray <
>>> etien...@chromium.org> wrote:
>>>
>>>> etien...@chromium.org
>>>>
>>>> ExplainerNone
>>>>
>>>> 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 affect 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 componentBlink>Scheduling
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling>
>>>>
>>>> TAG review
>>>>
>>>> TAG review statusNot 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, and by disabling the feature when WebRTC has
>>>> active connections in the process. 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
>>>>
>>>> *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?
>>>>
>>>>
>>>>
>>>> Goals for experimentation
>>>>
>>>> Gain insight on potential compatibility issues and evaluate impact on
>>>> guardian metrics (page load, latency).
>>>>
>>>>
>>>> Reason this experiment is being extended
>>>>
>>>>
>>>>
>>>> Ongoing technical constraints
>>>>
>>>>
>>>>
>>>> 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 namealign-wakeups
>>>>
>>>> Requires code in //chrome?False
>>>>
>>>> Tracking bughttps://crbug.com/1153139
>>>>
>>>> Estimated milestones
>>>> OriginTrial desktop last 105
>>>> OriginTrial desktop first 105
>>>> DevTrial on desktop 105
>>>> OriginTrial Android last 105
>>>> OriginTrial Android first 105
>>>> DevTrial on Android 105
>>>> OriginTrial webView last 105
>>>> OriginTrial webView first 105We plan to do a 1% Stable experiment for
>>>> M105 stable.
>>>>
>>>> Link to entry on the Chrome Platform Status
>>>> https://chromestatus.com/feature/5680188671655936
>>>>
>>>> --
>>>> 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/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%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/CAHOQ7J-pruChSM-Wm-cAtWUg6YuzBHumB%3D5Zdo8zjUMqJCn%3Dcg%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J-pruChSM-Wm-cAtWUg6YuzBHumB%3D5Zdo8zjUMqJCn%3Dcg%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/CAHOQ7J_7kWuBjXjQAjq4FJWy-vEYM4fH7W3f1%3DtU_SjSTErmSg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J_7kWuBjXjQAjq4FJWy-vEYM4fH7W3f1%3DtU_SjSTErmSg%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/CAL5BFfV7VwPG3PzD8JaGOn4SbmHDyNdPGWu8Xe0R13YxJA6vQw%40mail.gmail.com.
