I was out while this thread happened, but just wanted to chime in and say I'm super excited for this shipping!!
On Sat, Aug 24, 2024 at 12:22 AM Scott Haseley <shase...@chromium.org> wrote: > Thanks all! > > This will be enabled in M129. (Note: this just missed the M129 branch, so > it wasn't in the initial Chrome Beta release --- but has since been merged > <https://chromium-review.googlesource.com/c/chromium/src/+/5807457>, so > it should be in Beta soon.) > > On Wed, Aug 21, 2024 at 10:20 AM Alex Russell <slightly...@chromium.org> > wrote: > >> LGTM3 >> >> On Wednesday, August 21, 2024 at 9:06:12 AM UTC-7 Daniel Bratell wrote: >> >>> LGTM2 >>> >>> /Daniel >>> On 2024-08-16 04:44, Domenic Denicola wrote: >>> >>> LGTM1! >>> >>> Please consider updating the explainer a bit to capture where things >>> ended up, or at least adding a warning of some sort that it's a bit out of >>> date. >>> >>> I will, thanks for suggesting. > >> On Fri, Aug 16, 2024 at 12:33 AM Scott Haseley <shase...@chromium.org> >>> wrote: >>> >>>> On Wed, Aug 14, 2024 at 9:35 PM Domenic Denicola <dome...@chromium.org> >>>> wrote: >>>> >>>>> Very exciting to see this ready to ship after what sounds like a >>>>> successful experiment. A few small questions... >>>>> >>>>> On Sat, Aug 10, 2024 at 6:19 AM Scott Haseley <shase...@chromium.org> >>>>> wrote: >>>>> >>>>>> Contact emails shase...@chromium.org >>>>>> >>>>>> Explainer >>>>>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md >>>>>> >>>>>> https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-task-scheduling.md#scheduleryield >>>>>> >>>>>> *Note*: The explainer includes parameters to yield(), but we're >>>>>> initially shipping this with only the default behavior described in the >>>>>> specification. It wasn't clear if the parameters were necessary, there >>>>>> was >>>>>> some concern internally over the exact behavior >>>>>> <https://github.com/WICG/scheduling-apis/issues/96>, and it >>>>>> complicates the API. They may yet prove necessary, but it's safer to roll >>>>>> this out --- handling the main use case --- and revisit later, if needed. >>>>>> >>>>>> Specification >>>>>> https://wicg.github.io/scheduling-apis/#dom-scheduler-yield >>>>>> >>>>>> Summary >>>>>> >>>>>> Provides a method for yielding control to the browser, which can be >>>>>> used to break up long tasks. Awaiting the promise returned by >>>>>> scheduler.yield() causes the current task to yield, continuing in a new >>>>>> browser task. This can be used to improve responsiveness issues caused by >>>>>> long tasks. Continuations are prioritized to mitigate performance >>>>>> problems >>>>>> of existing alternatives. >>>>>> >>>>>> >>>>>> Blink component Blink>Scheduling>APIs >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling%3EAPIs> >>>>>> >>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/966 >>>>>> >>>>>> TAG review status Pending >>>>>> >>>>>> Chromium Trial Name SchedulerYield >>>>>> >>>>>> Link to origin trial feedback summary >>>>>> https://docs.google.com/document/d/1HSlhqWsamWyR9bwgtCzB2TpVW7CUm9QkyKbK0TdM0RA/edit?usp=sharing >>>>>> >>>>>> Origin Trial documentation link >>>>>> https://github.com/WICG/scheduling-apis/blob/main/implementation-status.md >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> This is a new feature and will not change existing event loop task >>>>>> scheduling, so the main risk is that other browsers might not implement >>>>>> the >>>>>> feature. There is an interop challenge, however, that comes with >>>>>> prioritization: we want to be specific enough to provide developers >>>>>> guarantees and interoperable implementations, but provide enough >>>>>> scheduling >>>>>> flexibility for UAs (like the HTML specification does with task >>>>>> sources/task queues), which we'll keep in mind while drafting the spec >>>>>> (see >>>>>> also https://github.com/WICG/scheduling-apis/issues/67). >>>>>> >>>>>> >>>>>> *Gecko*: Positive ( >>>>>> https://github.com/mozilla/standards-positions/issues/1039) Note >>>>>> that the issue opened for yield() was folded in with the original >>>>>> Scheduling APIs proposal, as this is an enhancement to that. >>>>>> >>>>>> *WebKit*: No signal ( >>>>>> https://github.com/WebKit/standards-positions/issues/361) >>>>>> >>>>>> *Web developers*: Positive >>>>>> >>>>>> Several partners were able to improve site performance using the API >>>>>> during Origin Trial (see the Origin Trial feedback link for quotes). >>>>>> >>>>>> Also some tweets I found with positive sentiment: >>>>>> - https://x.com/cramforce/status/1588912606777335808 >>>>>> - https://x.com/mohamedmansour/status/1752909705842933943 >>>>>> - https://x.com/sebastienlorber/status/1589939130225475584 >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> Ergonomics >>>>>> >>>>>> The default use (inserting yield points in long tasks) should enable >>>>>> Chrome to maintain better performance (responsiveness). There is a risk >>>>>> of >>>>>> continuations starving other work, but there are reasonable mitigations, >>>>>> e.g. bounding total of prioritized continuations (see also >>>>>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#preventing-task-starvation-by-continuations >>>>>> ). >>>>>> >>>>>> >>>>>> Activation >>>>>> >>>>>> The feature would benefit from a polyfill so that tasks still yield >>>>>> in the case the feature is unavailable. The behavior can be approximated >>>>>> by >>>>>> awaiting `scheduler.postTask()` or wrapping `setTimeout(0)` in a promise. >>>>>> The signal inheritance bit [1], however, would need transpilation support >>>>>> to propagate the current signal across async (Promise) boundaries. >>>>>> >>>>>> >>>>>> [1] >>>>>> https://docs.google.com/document/d/1rIOBBbkLh3w79hBrJ2IrZWmo5tzkVFc0spJHPE8iP-E/edit#heading=h.c484rp62uh2i >>>>>> >>>>>> Security >>>>>> >>>>>> >>>>>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#self-review-questionnaire-security-and-privacy >>>>>> https://wicg.github.io/scheduling-apis/#sec-security >>>>>> >>>>>> >>>>>> 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? >>>>>> >>>>>> No, this is a new API. >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> This has basic new-API devtools support. We plan to work with the >>>>>> devtools team to see if we can integrate continuations into the >>>>>> performance >>>>>> panel in some way. >>>>>> >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, 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> >>>>>> ? Yes >>>>>> >>>>>> >>>>>> https://wpt.fyi/results/scheduler/tentative/yield?label=experimental&label=master&aligned >>>>>> >>>>>> >>>>>> DevTrial instructions >>>>>> https://github.com/WICG/scheduling-apis/blob/main/implementation-status.md >>>>>> >>>>>> Flag name on chrome://flags --enable-blink-features=SchedulerYield >>>>>> >>>>>> Finch feature name None >>>>>> >>>>>> Non-finch justification None >>>>>> >>>>> >>>>> I think this should be no chrome://flags, and a Finch feature name of >>>>> SchedulerYield. (Assuming you got the default of having a base::Feature >>>>> generated from the Blink feature. >>>>> >>>> >>>> Ah, right. I did the default thing in runtime_enabled_features, so the >>>> Finch feature name would be SchedulerYield. I think the chrome://flags >>>> thing was left over from needing to provide the flag for dev trial. Updated >>>> in chromestatus. >>>> >>>> >>>>> >>>>>> >>>>>> Requires code in //chrome? False >>>>>> >>>>>> Tracking bug >>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=979020 >>>>>> >>>>>> Measurement Usage is measured by the SchedulerYield UseCounter: >>>>>> https://chromestatus.com/metrics/feature/popularity#SchedulerYield >>>>>> >>>>>> Availability expectation Initially available only in Chromium >>>>>> browsers. >>>>>> >>>>>> Adoption expectation Feature is a key part of optimizing long tasks, >>>>>> which contribute to poor responsiveness: >>>>>> https://web.dev/articles/optimize-long-tasks. Several partners are >>>>>> waiting for this API as part of INP optimization efforts. >>>>>> >>>>>> Adoption plan There has already communication with developers in >>>>>> anticipation of this API, e.g. >>>>>> https://web.dev/articles/optimize-long-tasks. I'll work with the >>>>>> devrel team on what additional communication may be required. >>>>>> >>>>>> Non-OSS dependencies >>>>>> >>>>>> Does the feature depend on any code or APIs outside the Chromium open >>>>>> source repository and its open-source dependencies to function? >>>>>> No. >>>>>> >>>>>> Estimated milestones >>>>>> Shipping on desktop 129 >>>>>> Origin trial desktop first 115 >>>>>> Origin trial desktop last 120 >>>>>> DevTrial on desktop 113 >>>>>> Shipping on Android 129 >>>>>> Origin trial Android first 115 >>>>>> Origin trial Android last 120 >>>>>> DevTrial on Android 113 >>>>>> Shipping on WebView 129 >>>>>> Origin trial WebView first 115 >>>>>> Origin trial WebView last 120 >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> >>>>>> No breaking changes are expected, but enhancements may be added as we >>>>>> learn more from usage. We also may need to adjust our internal scheduling >>>>>> policies (i.e. relative ordering of task sources) depending on what we >>>>>> learn from early adopters. >>>>>> >>>>>> The open issue that could potentially affect this API is the naming >>>>>> of related "yieldy" APIs: >>>>>> https://github.com/WICG/scheduling-apis/issues/95. This was raised >>>>>> in the WebKit position, specifically that scheduler.render() (future API >>>>>> enhancement) doesn't quite fit. We plan to name around scheduler.yield(), >>>>>> and are leaning towards rolling scheduler.render() in as a yield() >>>>>> parameter -- but this is still TBD. >>>>>> >>>>> >>>>> >>>>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#open-questions >>>>> lists a few open questions, which could have compat impacts. I suspect >>>>> that >>>>> section of the explainer just hasn't been updated. Can you confirm? >>>>> >>>> >>>> Confirmed. The outcome of those: >>>> >>>> >> 1. What should the default option be, inheritance or 'user-visible' >>>> priority? >>>> >>>> The API inherits the originating task's priority/signal if it was >>>> scheduled with scheduler.postTask() or requestIdleCallback ("background" >>>> priority continuation). >>>> >>>> >> 2. Does yield({priority}) set the priority to be inherited in future >>>> calls, or is the original signal used? >>>> >>>> This is what I mentioned in the explainer section. We removed the >>>> parameters (for now), so this no longer applies, but we'll have to revisit >>>> this if reinstating the parameters. >>>> >>>> >> 3. Should the API be allowed to return a resolved promise, if it >>>> knows it won't run other work? This could be more trouble than it's worth, >>>> but maybe there's potential to cut down (scheduling) overhead. >>>> >>>> We didn't end up pursuing this. >>>> >>>> >>>>> >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/6266249336586240?gate=6275382550986752 >>>>>> >>>>>> Links to previous Intent discussions Intent to Prototype: >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1SBQP-ABM3%2BsDtKzUZiPoSCWqW2mLOjMrUfFBx4TomSw%40mail.gmail.com >>>>>> Intent to Experiment: >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1Uj8nX5HrUT86iZ83YBj%3D6GJ4jnKZKYF3tOq%3D_twN_Yg%40mail.gmail.com >>>>>> >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> -- >>>>>> 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/CAKXGoJ3q%2BzPuSwBQ6Xp48aCP6m1kdE30Znh4wuzB_bL16UQwBg%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3q%2BzPuSwBQ6Xp48aCP6m1kdE30Znh4wuzB_bL16UQwBg%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/CAM0wra8bbQg5X__L1%2BJbWS_yr%3Dgf7WnNHEQgBtKG%2Bf99w7ZRjA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8bbQg5X__L1%2BJbWS_yr%3Dgf7WnNHEQgBtKG%2Bf99w7ZRjA%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/CAKXGoJ3pjM264fK9exzEKK6p347oLUrp-1-4wC79ZSYO5BeGAA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3pjM264fK9exzEKK6p347oLUrp-1-4wC79ZSYO5BeGAA%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/CAOmohSLeqgM0VkLArRLppieTcdiaUgiCh36chi5xvKqQ-smVCQ%40mail.gmail.com.
