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.
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 emailsshase...@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. >>> >>> Specificationhttps://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 componentBlink>Scheduling>APIs >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling%3EAPIs> >>> >>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/966 >>> >>> TAG review statusPending >>> >>> Chromium Trial NameSchedulerYield >>> >>> 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 nameNone >>> >>> Non-finch justificationNone >>> >> >> 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 bughttps://bugs.chromium.org/p/chromium/issues/detail?id=979020 >>> >>> MeasurementUsage is measured by the SchedulerYield UseCounter: >>> https://chromestatus.com/metrics/feature/popularity#SchedulerYield >>> >>> Availability expectationInitially available only in Chromium browsers. >>> >>> Adoption expectationFeature 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 planThere 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 discussionsIntent 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.
