Contact emails
fer...@chromium.org, dom...@chromium.org
Explainer
https://fergald.github.io/docs/explainers/queueMicrotask.html
Spec
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#microtask-queuing
Discussion: https://github.com/whatwg/html/issues/512
TAG review: https://github.com/w3ctag/design-reviews/issues/294
Summary
Add a new method self.queueMicrotask(callback) to allow direct queueing of a microtask.
Motivation
There are many existing ways to queue asynchronous work on the platform, including setTimeout(,0)/the Edge-only setImmediate(); requestAnimationFrame(); and requestIdleCallback(). However, all of them yield to the browser's event loop.
Web developers often want to perform some work as soon as possible, without yielding, but still "async". This is especially useful for operations which can be completed immediately (e.g. serviced from cache). The web platform's primitive for this is queuing a microtask. Developers and frameworks are already queuing their own microtasks by using Promise.resolve().then(callback) or MutationObservers. This API exposes the microtask-queuing primitive directly.
Risks
Interoperability and Compatibility
Low
Edge: positive signals
Firefox: some support, back in 2016
Safari: no signals
Web developers: Positive, seen on github discussion above and by the many frameworks using hacks to work around this (Angular, Ember, Vue, asap dependents...)
Ergonomics
This is making directly available an action that is currently hackily performed. As such it's an ergonomic win.
Activation
Frameworks and developers can use this immediately as-is.
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?
Yes: https://wpt.fyi/results/html/webappapis/microtask-queuing
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5111086432911360
Requesting approval to ship?
Yes
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHL%3DFNnmFNuCJ%2BN1-bwYqndBa_J%2BjspwRB74vhuFWXyUS4w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHOCEjPNZ61MfPU%2BsNzPpN50XqYDbYo5V7v0rDYgJNPfw%40mail.gmail.com.
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/CAFpjS_2aB3ED7NLf%2BBVKXZUovw%3DNFvT9kYPBDWXsoD3FoJrGLA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zou26vnorbppqq%40cicero2.linkoping.osa.
Spec
Risks
Thanks.Ben
Can you elaborate on "the old mitigations for setTimeout()"? I'm not familiar with this,
On Wed, Sep 5, 2018, 10:44 PM Fergal Daly <fer...@google.com> wrote:Can you elaborate on "the old mitigations for setTimeout()"? I'm not familiar with this,Sites have a long history of accidentally triggering infinite or exponentially expanding setTimeout() chains. To mitigate this problem browsers instituted a 4ms minimum delay on deeply nested setTimeout() calls.
queueMicrotask() resembles an API with a history of problems and those problems could be worse due to microtasks being effectively sync. I guess it seems like a risk to me.Note, I think the problem could be effectively addressed by adding an anti-abuse clause in the spec. Something like "if the browser has been running a task longer than X with microtask nesting depth greater than Y, then the browser may optionally queue a task instead of a microtask to restore interactivity". If X and Y are set high, this would allow script to use it as intended while also allowing browsers the flexibility to mitigate abuse.
Anyway, I guess that kind of thing can be added to the spec later if necessary. I just wanted to make sure the risk was at least discussed here.
Thanks.Ben