LGTM to roll out the "optimistic shipping" plan up to beta. Then please come back to this thread for final shipping approval.
On Wed, Aug 24, 2022 at 1:38 PM Chris Harrelson <chris...@chromium.org> wrote: > > > On Wed, Aug 24, 2022 at 1:35 PM Etienne Pierre-doray < > etien...@chromium.org> wrote: > >> 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. >> > > I think that's fine. > > >> >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsZZOFiB3y%3DG_iWZPx1h387wA7DpPrR4s-NP3kBkoGU-JA%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%2Bw97OdB%3DetZjGMxjrfZJyWbprG3%3D-aRc5y3dgesjNBm6JQ%40mail.gmail.com.
