> > Ok. So your experiment is not an OT, but rather asking permission for an > A/B (finch) experiment on those channels? > Correct, I very recently discovered the difference between finch and OT; sorry for the confusion.
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. > That sounds like a reasonable plan. Is it still ok to run 1% experiment on M105 stable meanwhile. Per yoavweiss@ previous response, this is mostly aimed at evaluating performance/power benefits. On Wed, Aug 24, 2022 at 3:16 PM Chelbi Owre <chelbio...@gmail.com> wrote: > Fuck off > > On Wed, Aug 24, 2022 at 12:15 PM Chris Harrelson <chris...@chromium.org> > wrote: > >> >> >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8i4paLPo0X57Xn3YWm--SEW5gbk_paRCrHqqEZ90ukSA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > Chelbi Thyme > -- 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/CALoDvsZZOFiB3y%3DG_iWZPx1h387wA7DpPrR4s-NP3kBkoGU-JA%40mail.gmail.com.
