Hi Blink API Owners, Thanks for taking the time to look into this feature.
> Do I understand correctly that you're asking for experimentation only in > the 105? > This is correct. Although I imagined the following rollout plan, with a separate I2S once I gathered data on Stable: - (previously) 50% on canary/dev/beta M103/M104 - 50% canary/dev/beta + 1% Stable on M105 - 100% Stable on M106 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). > What would be a suitable roll-out plan to expose compat issues? In similar performance interventions (e.g. Intensive throttling <https://groups.google.com/a/chromium.org/g/blink-dev/c/8En_5DqV_fU/m/P23eNeUWAgAJ>), origin trial (on 50% Beta and 1% Stable) was able to surface issues and provide necessary feedback for launch to be LGTM-ed. On Thu, Aug 11, 2022 at 5:16 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > 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/CALoDvsakspNqSSOJCLvELQiHy_L7jkFzCFWTHEsEXVEaOS9EQw%40mail.gmail.com.
