Intent to Ship: Scheduling APIs: Prioritized scheduler.postTask

[Scott Haseley]

Contact emails

shas...@chromium.org, jap...@chromium.org

Explainer

https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-post-task.md

Specification

https://wicg.github.io/scheduling-apis/

API spec

Yes

Design docs

https://docs.google.com/document/d/1Apz-SD-pOagGeyWxIpgOi0ARNkrCrELhPdm18eeu9tw/edit?usp=sharing

Summary

Userspace tasks often have varying degrees of importance (related to user experience), but the Platform lacks a unified API to schedule prioritized work. The postTask API allows developers to schedule tasks (javascript callbacks) with a native browser scheduler at 3 levels of priority: user-blocking, user-visible, and background. It also exposes a TaskController, which can be used to dynamically cancel tasks and change their priority.

Blink component

Blink>Scheduling

Search tags

scheduling, scheduler, main thread, main-thread

TAG review

https://github.com/w3ctag/design-reviews/issues/647

We're waiting on the TAG spec review, but the pre-spec TAG review is here: https://github.com/w3ctag/design-reviews/issues/338

TAG review status

Pending

Risks

Interoperability and Compatibility

Since this is a new feature, the main risk is that it fails to be adopted by other browsers. This carries some adoption risk since scheduling can be a fundamental part of an app's architecture. But this API is polyfillable, which helps mitigate this risk.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/546)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-June/031912.html). Ryosuke has been concerned with the risk of priority inversion, which we’ve explored and written about here: https://github.com/WICG/scheduling-apis/blob/main/misc/priority-inversion.md.

Web developers: Positive

 - We've worked closely with React and Airbnb while designing this API, and both are planning to use the API. Airbnb wrote about there uses cases and performance improvements using the API here: https://medium.com/airbnb-engineering/building-a-faster-web-experience-with-the-posttask-scheduler-276b83454e91

React mentioned the partnership and planned adoption of the API in this thread: https://twitter.com/acdlite/status/1410609223705133074

- The tracking bug (crbug.com/979017) has 9 stars

- Blog post about using the API behind a flag: https://dev.to/nielsen-tlv/the-hidden-magic-of-main-thread-scheduling-16i9

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with? Abort[Controller|Signal]

Could the default usage of this API make it hard for Chrome to maintain good performance? Unlikely. There is always concern around starvation and abuse when introducing (higher) priorities. But it is always a possibility that script just won't yield (or queue microtasks, or abuse rAF); the scheduling mechanisms introduced here are intended to allow pages to improve their performance as an alternative to such non-yielding behavior. We will continue, however, to evaluate this as API adoption grows.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is? No.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use? Yes. We plan to extend postTask to support more features, but in the meantime libraries will probably be helpful (e.g. event-based delays and timeouts). A polyfill will be very helpful since scheduling tends to be very integrated into a site's design. We have  polyfill that was used by a partner during origin trial that we plan to publish (tracking issue: https://github.com/WICG/scheduling-apis/issues/37)

Security

https://wicg.github.io/scheduling-apis/#sec-security

Debuggability

Exposing the task priority in performance traces would probably be quite helpful, as would showing where a task was scheduled. Tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1225752.

Is this feature fully tested by web-platform-tests?

Yes

DevTrial instructions

https://github.com/WICG/scheduling-apis/blob/main/implementation-status.md

Flag name

--enable-blink-features=WebScheduler

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=979017

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1048941

Measurement

https://www.chromestatus.com/metrics/feature/popularity#SchedulerPostTask

https://www.chromestatus.com/metrics/feature/popularity#TaskControllerSetPriority

https://www.chromestatus.com/metrics/feature/popularity#TaskSignalPriority

Sample links

https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-post-task.md

https://github.com/WICG/main-thread-scheduling/tree/master/sample-code

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/6031161734201344

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/HvqbB7TGJKU/m/Kd0WUGXkAQAJ

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/QMQz7rWADO0/m/UYYZJMMOAQAJ

Comments

 - https://github.com/WICG/scheduling-apis/issues/26 will be addressed prior to shipping, we're just waiting on TAG input (I've just requested this outside of our TAG review).

 - We plan to address https://github.com/WICG/scheduling-apis/issues/24 after shipping, which is that isInputPending is on navigator.scheduling and we specced postTask on window.scheduler. Our plan is to move isInputPending to window.scheduler by

  1.  Updating the isInputPending spec to define it on window.scheduler

  2.  Aliasing navigator.scheduling.isInputPending to window.scheduler and doing outreach

  3. Watching UseCounters and deprecating navigator.scheduling.isInputPending

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

LGTM1 conditional on TAG input on issue #26, as mentioned below.

Amazing work driving this API, incorporating feedback from the WebPerfWG and from partners.

That's an amazing signal!

[Mike West]

LGTM2.

Thank you in particular for the well-developed security considerations doc, and the related conversations about the potential risks of task timing.

-mike

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/972e1ec0-a096-4aa9-82ac-4f560a43b8a3n%40chromium.org.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DchC9ib_7jq7HmJT8ytd671C3V%2BG%3DHMNed1ZrVqL_YjZg%40mail.gmail.com.

[Scott Haseley]

Thanks all! Regarding issue #26, unfortunately we haven't received a response from TAG folks yet via design review or on the issue itself. I went ahead and made the change to better future-proof the API, which IMO is unlikely to be controversial given it's in line with TAG guidance.

Is it okay to ship now, or should we continue to wait for TAG feedback? I'm not sure what an appropriate amount of time to wait is. Our design review has been pushed back several times, and it's currently flagged for the Aug 9 week --- which is the week of the M94 branch. I'd like to avoid pushing this back another milestone if possible, but want to make sure we've waited long enough. Keep in mind that the pre-spec review ended favorably and that the delta from that is not very large.

Thanks,

Scott

[Chris Harrelson]

On Thu, Jul 29, 2021 at 1:21 PM Scott Haseley <shas...@chromium.org> wrote:

Thanks all! Regarding issue #26, unfortunately we haven't received a response from TAG folks yet via design review or on the issue itself. I went ahead and made the change to better future-proof the API, which IMO is unlikely to be controversial given it's in line with TAG guidance.

Is it okay to ship now, or should we continue to wait for TAG feedback?

It's ok to ship now. If for some reason the TAG comes back with more things they want to change, you could always consider adjusting the code while it's still in the early channels.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1d8YwxaZDKQsCoRmmPh5vKBHG2wdK5Gev02VAhSsWPGg%40mail.gmail.com.

[Scott Haseley]

Sounds good, thanks Chris!