Unclear if microtasks are running as often as they should

[domenic]

See discussion starting at whatwg/webidl#113 (comment)

@bzbarsky has, I believe, two concerns with the current model, which runs microtasks when the JavaScript execution context stack is empty:

• This means that when the user clicks, microtasks happen after every click listener (since there is no code on the stack below each click listener); but when the page does el.click(), microtasks do not happen until the stack fully unwinds.
• This means that during alert/confirm/prompt, as these are currently specified, no microtasks run.

In my opinion the first of these is not a problem, but I'd be interested in fixing the spec for alert/confirm/prompt to allow UAs to be a bit more responsive during the "pause".

[bzbarsky]

@smaug---- Do you recall whether mutation observers run exactly off microtasks and if not what prevented that?

[annevk]

Mutation observers has this model too (only invoke when the stack is empty, which indeed has the difference between a user click and click()). What makes mutation observers special is that each mutation doesn't queue a microtask. But we handle a whole bunch of them in a single one, a compound microtask.

[smaug----]

This means that when the user clicks, microtasks happen after every click listener (since there is no code on the stack below each click listener); but when the page does el.click(), microtasks do not happen until the stack fully unwinds.

Yes, microtasks were very much designed to behave this way.

And microtaks don't run during alert/confirm/prompt/etc. In Gecko, given the event loop model we have currently, this works usually, but once you start playing with multiple tabs, things may go wrong.

[bzbarsky]

So the big problem here is that the spec as written is making a fundamental assumption: The user cannot interact with the browser while the JS stack is nonempty.

This assumption is bogus given alert/confirm/etc in browsers that do not make them app-modal. Which is more and more browsers (e.g. iOS Safari made moves in this direction).

I think we need a note here, at the very least, pointing out that the spec is in flux. Otherwise we get in a cycle of some UAs claiming "but the spec says X, so we must do X" and other UAs saying "but it says this based on bogus premises that aren't actually true except maybe in your particular implementation" and then we end up with things like https://www.w3.org/Bugs/Public/show_bug.cgi?id=11960. Been there, done that, don't want to end up there again.

[domenic]

Can you explain where the spec is making that assumption?

[bzbarsky]

Sure. Here's a simple example. I have a web page loaded in tab 1. I click a button on it, that button opens a new tab 2 with a second page. In tab 2 I do something that causes an alert() to happen. I leave the alert be, switch back to tab 1, interact with the page in tab 1. Per the letter of the spec, this interaction must be blocked, because the alert is supposed to not let the event loop spin until it comes down. This is user-hostile, and not something the spec should be requiring from UAs.

Now given that, say a user clicks something in tab 1. Say the event listeners queue microtasks. When do those run? Well, per letter of spec this situation can't even arise. But if you accept that the event loop keeps going while the alert is up but accept everything else in the spec, then they will run at the next event loop turn, whereas if the alert were not up they would run after every listener.

Now maybe the idea is that alert should https://html.spec.whatwg.org/multipage/webappapis.html#spin-the-event-loop (which is not referenced anywhere, by the way) but that's not clear from the spec at all....

[domenic]

That makes sense, thanks. I'll try to work on a note, or maybe spin the event loop...

(which is not referenced anywhere, by the way)

You seem to have been bitten by the classic "dfn.js sucks at multipage" bug. It's referenced a lot, but you have to open singlepage to find them :(