scheduler.postTask()
Closed this issue · 1 comments
Ya ya yawm TAG!
I'm requesting a TAG review of scheduler.postTask().
Userspace tasks often have varying degrees of importance (related to user experience), but the Platform lacks a unified API to schedule and control prioritized work; scheduler.postTask() provides this functionality.
- Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-post-task.md
- Specification URL: https://wicg.github.io/scheduling-apis/
- Tests: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/scheduler/. Note: we are in the process of moving these to the wpt repo.
- Security and Privacy self-review²: https://github.com/WICG/scheduling-apis/blob/main/explainers/security-privacy-questionnaire-post-task.md
- GitHub repo (if you prefer feedback filed there): https://github.com/WICG/scheduling-apis/
- Primary contacts (and their relationship to the specification):
- Scott Haseley (@shaseley), Google, spec editor
- Organization(s)/project(s) driving the specification: Google/Scheduling APIs
- Key pieces of existing multi-stakeholder review or discussion of this specification: This API has been discussed several times (pre-spec) in the WebPerf WG, with links to talks here
- External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/features/6031161734201344
Further details:
- I have reviewed the TAG's Web Platform Design Principles
- Relevant time constraints or deadlines: We hope to ship this API in Chrome version M93
- The group where the work on this specification is currently being done: WebPerf WG
- The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):
- Major unresolved issues with or opposition to this specification:
- This work is being funded by: Google
You should also know that...
- The previous TAG review for this work (pre-spec) can be found here. Two things that changed have since that review:
- Removal of callback arguments
- Addition of previousPriority to priority change events
- We would appreciate TAG feedback on this open issue
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback
CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING
Please preview the issue and check that the links work before submitting.
In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.
¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.
² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.
Sorry this took so long - I believe this was a priority request and for some reason, it fell through the cracks. We looked at this during our breakout today and were very happy to see all the security concerns properly addressed in the draft spec, and are happy to see a feature that would be useful for developers finally landing on the platform. For these reasons, we're happy to see this proceed.
Thanks for bringing this to our attention, and sincere apologies it took so long.