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
<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/946c0563-cdd6-483b-93e1-deca23b6bd27%40sarasas.se.
