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/CAKXGoJ1uZOFEpDdw8VsR3h3B_8tSCL-_Ex1M_peFOtrEfm05-w%40mail.gmail.com.
