Contact emails
Spec
I'd claim that the current spec is contradictionary here, see summary:
Summary
Some APIs, namely, alert, prompt, confirm, print, and sync XHRs will spin the message loop.
On the other hand, microtasks are supposed to be executed at the end of the task that created them.
When a web page invokes one of the former APIs during microtask execution, we might end up executing regular tasks during microtask execution, e.g., resizing the browser window will fire resize events at the window.
It's also unclear whether microtasks created during those events should be executed at the end of the task corresponding to the event, or whether they should be enqueued at the end of the outer microtask queue.
I propose to plainly disallow those APIs during microtask execution.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Demo link
layout tests included in https://codereview.chromium.org/1940253002
Debuggability
When we block an call, a console error is logged.
Interoperability and Compatibility Risk
I checked Firefox, and they don't block those calls during microtask execution, and suffer from the same issue I described above.
I asked on #whatwg and the general feeling of all three that answered was that the risk might be low :)
OTOH, I expect this to happen rarely in practice.
OWP launch tracking bug
Entry on the feature dashboard
none yet.
Sync XHRs will result in progress events being dispatched while the nested message loop runs.
I think this is very high risk, it means using any library that contains an alert will fail when used inside a promise callback, and nearly every new feature uses Promises. For example it would mean alert works in the event version of IDB, but is broken in the Promise version of the same api.
The print one in particular is going to be very confusing for developers, it doesn't really make sense that you can invoke it from an XHR callback but not a fetch Promise. Is there an async version of print?
This would also likely break apps written with a modern framework like Polymer, but that use any old style modal (usually inside some third party library wrapped in a component) since they schedule lots of work inside microtasks as a way to defer things.
I think we need to add a UseCounter for how often this would trigger before shipping it. It seems so easy to stumble into it by mistake, left hand doing the scheduling, right hand doing the UI in your app and then be broken.
I'm not sure I agree - I think the overlap you describe is quite rare. But anyways, adding a use counter, and preferably a deprecation message sounds fine as a first step
--
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.
How easy is it to revert? I'm fine letting it go all the way to beta as long as it's a tiny low risk revert to bring it back.
Yeah, syncXHR is the surprising outlier. I guess you can still work around this by moving the entire promise handler into a setTimeout.
I also don't think we're stuck forever with this, as we want to get rid of syncXHR, and for the dialogs we'll soon(ish) return immediately for background tabs at which point not blocking will be there rule and not the exception
And for syncXHR's we'll throw an exception, so hopefully the existing error handing kicks in