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. > > 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/046b5827-105c-4270-a9e6-2c80d6505f22n%40chromium.org.
