On Thu, Aug 11, 2022 at 8:48 AM Etienne Pierre-doray <etien...@chromium.org> wrote:
> 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 > Ok. So your experiment is not an OT, but rather asking permission for an A/B (finch) experiment on those channels? > > 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. > We discussed this intent at the API owners meeting today. 50% beta may not yield the feedback you want, because developers or users may conclude that an apparent breakage is a non-reproducible bug because it only reproduces some of the time or on some computers. To correct for this, and given you hope to ship it in one release, I suggest an "optimistic shipping" strategy: 1. Turn on (via finch) for canary/dev at 100% for canary / dev version N 2. Continue to beta at 100% for version N assuming no bugs reported in step 1 3. After 2.5 weeks at beta with no bugs reported, send an I2S to blink-dev, which we'd approve assuming no issues were reported 4a. Assuming 3 succeeds, proceed to 100% stable when N ships 4b. Assuming it fails, turn off the experiment in beta. This will still leave 1.5 weeks of testing without the change as part of the normal release cycle This plan is designed to avoid the not-reproducible-bug issue, and also satisfy the need for us to test what is actually shipping on the beta channel. At present N would be 107. > > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsakspNqSSOJCLvELQiHy_L7jkFzCFWTHEsEXVEaOS9EQw%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/CAOMQ%2Bw8i4paLPo0X57Xn3YWm--SEW5gbk_paRCrHqqEZ90ukSA%40mail.gmail.com.
