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.
