Hi API Owners, I'd like to extend the initial OT for two milestones (through M120). We've fixed some bugs and have had some recent signups, so I'd like to make sure folks have enough time to experiment. The initial OT was configured for 4 milestones, so 2 additional would take this to the max of 6.
Thanks, Scott On Wed, Jun 14, 2023 at 3:02 PM Scott Haseley <[email protected]> wrote: > On Tue, Jun 13, 2023 at 7:02 PM Domenic Denicola <[email protected]> > wrote: > >> Exciting stuff!! >> >> > The signal inheritance bit [1], however, would need transpilation >> support to propagate the current signal across async (Promise) boundaries. >> >> I couldn't find where this [1] goes. I'm very interested in this general >> area, and questions like whether we propagate by default or not, and how >> robust the propagation is to different mechanisms (e.g., not just promises, >> but other web platform callbacks as well). >> >> What's the latest source of information on that, either in our >> implementation or in the explainer/spec? I see from the explainer there's a >> non-default `signal: "inherit"`, but I couldn't find details on how "the >> current task"'s priority is determined and propagated. >> > > Ah, sorry, not sure what happened there; that was probably pointing to the > design > discussion section > <https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#priority--abort-propagation-behavior> > . > > It's still an open question of whether or not inheritance should be the > default here, hoping to work that out soon. I just brain-dumped the current > state of things in this doc > <https://docs.google.com/document/d/1rIOBBbkLh3w79hBrJ2IrZWmo5tzkVFc0spJHPE8iP-E/edit?usp=sharing>, > with details about what gets propagated and how that works, along with code > pointers. I'm planning to begin the spec work on this soon, in parallel > with OT. > > On Wed, Jun 14, 2023 at 2:53 AM Scott Haseley <[email protected]> >> wrote: >> >>> Contact [email protected] >>> >>> Explainer >>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md >>> >>> SpecificationNone >>> >>> 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/827 >>> >>> TAG review statusPending >>> >>> 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*: No signal >>> >>> *WebKit*: No signal >>> >>> *Web developers*: No signals >>> >>> *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. But >>> developers can alternatively pass the appropriate priority/signal if >>> necessary on browsers that don't support the feature. >>> >>> >>> Security >>> >>> See >>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#self-review-questionnaire-security-and-privacy >>> >>> >>> 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? >>> >>> None >>> >>> >>> Goals for experimentation >>> >>> The main goal is to evaluate yielding with prioritized continuations on >>> site-specific metrics. More frequent yielding is known to improve >>> responsiveness (should also be measured in experiments), but there's often >>> a cost (latency) to regaining control of the thread. This API prioritizes >>> continuations to mitigate this, and we want to measure the impact on >>> site-specific metrics to evaluate the scheduling behavior. >>> >>> >>> Ongoing technical constraints >>> >>> None. >>> >>> >>> 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, Chrome OS, 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 >>> >>> DevTrial instructions >>> https://github.com/WICG/scheduling-apis/blob/main/implementation-status.md >>> >>> Flag name--enable-blink-features=SchedulerYield >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=979020 >>> >>> Estimated milestones >>> OriginTrial desktop last 118 >>> OriginTrial desktop first 115 >>> DevTrial on desktop 113 >>> OriginTrial Android last 118 >>> OriginTrial Android first 115 >>> DevTrial on Android 113 >>> OriginTrial webView last 118 >>> OriginTrial webView first 115 >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/6266249336586240 >>> >>> Links to previous Intent discussionsIntent to prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1SBQP-ABM3%2BsDtKzUZiPoSCWqW2mLOjMrUfFBx4TomSw%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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1Uj8nX5HrUT86iZ83YBj%3D6GJ4jnKZKYF3tOq%3D_twN_Yg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1Uj8nX5HrUT86iZ83YBj%3D6GJ4jnKZKYF3tOq%3D_twN_Yg%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3kOKppN1cEFr8RkN1T%2ByoEj%2BtLmUTMs5Z9hnLJh6wYUQ%40mail.gmail.com.
