Intent to Ship: Scheduling APIs: Prioritized scheduler.postTask

183 views
Skip to first unread message

Scott Haseley

unread,
Jul 1, 2021, 5:26:15 PMJul 1
to blink-dev

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

unread,
Jul 8, 2021, 5:18:03 AMJul 8
to blink-dev, Scott Haseley
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

unread,
Jul 12, 2021, 9:24:56 AMJul 12
to Yoav Weiss, blink-dev, Scott Haseley
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

unread,
Jul 15, 2021, 3:15:12 PMJul 15
to Mike West, Yoav Weiss, blink-dev, Scott Haseley

Scott Haseley

unread,
Jul 29, 2021, 4:21:53 PMJul 29
to Daniel Bratell, Mike West, Yoav Weiss, blink-dev
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

unread,
Jul 29, 2021, 4:23:54 PMJul 29
to Scott Haseley, Daniel Bratell, Mike West, Yoav Weiss, blink-dev
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.
 

Scott Haseley

unread,
Jul 29, 2021, 4:35:44 PMJul 29
to Chris Harrelson, Daniel Bratell, Mike West, Yoav Weiss, blink-dev
Sounds good, thanks Chris!
Reply all
Reply to author
Forward
0 new messages