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%2Bw8dKRnf2vmErbSC_2f8YQziDpWrBFJ0JpwuVzn0M%3DKs7A%40mail.gmail.com.
