Intent to Implement and Ship: queueMicrotask

[Fergal Daly]

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

[TAMURA, Kent]

LGTM1.

It seems WebKit already implemented it.

https://trac.webkit.org/changeset/234491/webkit

https://trac.webkit.org/changeset/234588/webkit

--
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.

--

TAMURA Kent
Software Engineer, Google

[Hayato Ito]

Non-owner LGTM. This is an ergonomic win.

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

--

Hayato

[Daniel Bratell]

LGTM2

/Daniel

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.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Yoav Weiss]

LGTM3 given WebKit's implementation.

It seems like they added their own tests rather than importing the ones from the WPT test suite. Would be great to make sure their implementation also passes the WPT ones, and if not, file bugs against it.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zou26vnorbppqq%40cicero2.linkoping.osa.

[Ben Kelly]

On Tue, Sep 4, 2018, 10:26 PM 'Fergal Daly' via blink-dev <blin...@chromium.org> wrote:

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

Risks

The spec issue contains some concerns.

In particular, the main risk seems to be infinite sync loops via an async-like API.  While possible with promises and mutation observers today, this expands the API surface that can trigger that result and arguably in a way that is easier than before.  (The web has run into similar problems with direct callback APIs like setTimeout(f,0)...)

 

How do you plan to address that in your implementation?

Assuming the answer is "slow script dialog", are you planning to measure slow script triggers that involve this API?  What is the mitigation if slow script triggers increase and become a problem for users?  It seems the old mitigations for setTimeout() require posting tasks which can't be used here.

Thanks.

Ben

[Fergal Daly]

"slow script dialog" is the answer. There were no plans to measure this. There are 2 cases, abuse and accidental.

Abuse doesn't seem any different from an abusive "while (true) {}" and I don't think reporting is helpful.

For the accidental case, I'm not sure how we could do anything very useful. There's no reason to anticipate wide-spread incorrect usage of this API but if it happens then the developers themselves will get slow script dialogs and presumably fix things. It's possible that for some sites the users will suffer and the devs will not pay attention but that also applies to any feature and there's not much we can do. The number of sites that bother to use this API but pay no attention to poor outcomes should be very small.

The reporting API seems like a great way to communicate problems like this back to devs that care about the user experience. I don't know if slow script dialogs currently make it into that (a quick experiment shows nothing in the console when I trigger the dialog, so I guess not) but that seems like the best way to ensure that problems are communicated back to the people who can take action.

Can you elaborate on "the old mitigations for setTimeout()"? I'm not familiar with this,

F

 

Thanks.

Ben

[Ben Kelly]

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

[Fergal Daly]

On 6 September 2018 at 12:13, Ben Kelly <wande...@chromium.org> wrote:

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.

Thanks.

With the different semantics, the impact will be different. With infinite setTimeout chains, the slow script dialog presumably did not fire since it was constantly yielding to the event loop. This would result in long-running silent CPU hogging. With queueMicrotask, the slow page dialog will kick in soon and the user can kill it. Even before the dialog appears the page will be completely unresponsive, not even scrolling. It seems like it would be much harder to accidentally publish a site with this problem and if you do, it's very noticeable. These differencess the risk seem much lower to me.

 

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.

Posting microtasks into a follow-on task could result in a big semantic change. E.g. a page may be in an inconsistent state until all microstasks have completed. Allowing a task for e.g. input handling before that does not seem OK. I think it's preferrable to have only 2 options, complete fully or fail visibly (with slow script dialog etc),

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.

Yes. If you're convinced by the above, I'll summarize it in the explainer because it wasn't obvious to me,

F

 

Thanks.

Ben