See discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24484#c2

After trying to implement this in Blink, I've changed my mind about thinking this is reasonable. In short, the more places that provide a stable state, the more cases have to be tested for every algorithm that awaits a stable state. In this case, cross-browser testing using plain scripts is not possible because scripts have no way of dismissing these dialogs, since they are blocked waiting for them.

Hixie said this in the linked bug:

> Consider the case of a page that create a video element, then does
> alert("Ok, I've started the load!"). The user sees the alert, thinks "I'll
> go for lunch while it loads", comes back... and we haven't yet started the
> load, if we don't provide a stable state here.

This is not an impossible scenario, but providing for it does not seem worth the added implementation and testing effort.

Question: Am I understanding the spec language correctly that "spin the event loop" synchronously triggers "perform a microtask checkpoint" before returning to the event loop?

Would imply that calling showModalDialog would synchronously run all pending microtasks, and the parser discovering that it is blocked on a "style sheet that is blocking scripts" would also synchronously run all pending microtasks?

Relevant discussion on IRC:

http://krijnhoetmer.nl/irc-logs/whatwg/20140219#l-367
http://krijnhoetmer.nl/irc-logs/whatwg/20140219#l-868

I don't understand why we would not want to provide a stable state when the whole browser is blocked on an alert. It's the ultimate stable state, and preventing downloads from starting in that state seems really bad.

It seems bad for users primarily, but also authors. It might be more complicated for implementors, but users and authors are more important.

(In reply to Ian 'Hixie' Hickson from comment #4)
> I don't understand why we would not want to provide a stable state when the
> whole browser is blocked on an alert. It's the ultimate stable state, and
> preventing downloads from starting in that state seems really bad.
> 
> It seems bad for users primarily, but also authors. It might be more
> complicated for implementors, but users and authors are more important.

What about what zcorpan pointed out, that alert() is used for debugging? This seems like a problem:

v1.src = 'foo';
alert(v1.src); // removing this line changes the behavior of the next
v2.src = v1.currentSrc;

Debugging this doesn't seem like fun at all.

*shrug*

That seems less bad to me. I agree that it could be argued both ways.

If you really think we should block media loads until the script is over, even in the case of the script calling alert(), then ok. But we should make sure to test that that is actually implemented.

I wrote a test for alert, confirm and prompt:
https://github.com/w3c/web-platform-tests/pull/659

I was rather surprised to find that Firefox and IE11 pass the tests.

But yeah, I still think that the use case for providing a stable state here is very dubious, and if this is going to be the only remaining case where a stable state could occur while scripts are running I definitely don't think it's worth it.

Ok, but are Firefox and IE going to _stop_ downloading in that case?

roc and cdouble, would you be willing to change Gecko to *not* provide a stable state for blocking dialogs? I think the example in comment #5 is the strongest reason to not do it.

console.log and other tools are better than alert() anyway. I don't see a reason to change here.

(In reply to Robert O'Callahan (Mozilla) from comment #11)
> console.log and other tools are better than alert() anyway. I don't see a
> reason to change here.

What do you think should be done if this is the only "provide a stable state" that cannot be expressed in terms of microtasks in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24724 ?

I wouldn't stand in the way of that.

OK, I guess that bug should be resolved first then, to see if this will actually be the odd man out.

foolip, do you have an update on what happened to the test for this? I really think we should make sure to have a test for this (with the behaviour being that alert() blocks the download of video content for elements created in the same script block before the alert()), because I am not confident that browsers will maintain this behaviour if we spec it.

Looks like I forgot to re-open that pull request as I planned, so here's a new one:
https://github.com/w3c/web-platform-tests/pull/970

This is testing the current spec behavior, and if you change the spec I'll just invert the pass condition.

Done.

This is open to help me track the aforementioned test, so that I don't forget to undo this change if browsers decide to load the file during an alert() anyway.

https://github.com/w3c/web-platform-tests/pull/970#issuecomment-52169507