Steps to reproduce: 1) Open Web Console. 2) Load http://hsivonen.iki.fi/test/moz/premature-script-execution/test-external-log.html 3) Now load http://hsivonen.iki.fi/test/moz/premature-script-execution/test-external-alert.html for comparison. 4) For comparison, load http://hsivonen.iki.fi/test/moz/premature-script-execution/test-external-alert.html in other browsers. Actual results: When console.log() is used, the logged messages appear in the order that is correct according to HTML5 and the run-to-completion JavaScript execution semantics. That is, the message from the inserter script appears first and the the message from the external script appears second. When alert() is used in any other browser (IE9, Safari 5, Opera 11, Chrome 9 and 10), the messages appear in the same order as console.log() messages appear in Minefield. However, when alert() is used in Minefield, the messages appear in the wrong order. Expected results: Expected alert() messages in Firefox to show in the same order as console.log() in Firefox and alert() in every other browser.

More verbose testcase: http://dolske.net/mozilla/tests/prompt/script_load_order.html With both tab-modal and window-modal prompts, both scripts begin execution, as you can see from the console.log() output. The difference in behavior is because we (currently) don't block multiple concurrent alerts, but just place the most recent one on top. I suppose we could place it on the bottom, in which case you'd get the same behavior as window-modal prompts... That is, the main page's alert() would be on top, but that script's execution wouldn't resume immediately upon clicking OK because the 2nd event loop on top (for the subscript's prompt) is still spinning. Is this actually spec'd?

(Note: you can test the window-modal behavior flavor in Firefox by toggling the prompts.tab_modal.enabled pref)

(In reply to comment #1) > Is this actually spec'd? Yes: http://www.whatwg.org/specs/web-apps/current-work/#dom-alert http://www.whatwg.org/specs/web-apps/current-work/#prepare-a-script http://www.whatwg.org/specs/web-apps/current-work/#pause I guess the conclusion is that to get the right behavior, we'd need per-window (or per constellation of window objects that are reachable from each other, rather) task queues instead of a global task queue for most non-user events (including network tasks and continuation tasks posted by the script loader).

Maybe this should be treated as a script loader bug instead. What's the right way to ask a window object if it has been paused due to a modal dialog? nsGlobalWindow::IsFrozen? Do timers get suspended in window objects reachable (via .parent, .opener, etc.) from the window that has an alert open?

I think that to get this right in general, we do need to implement the HTML5 event model, which does have lots and lots of separate task queues.

(In reply to comment #5) > I think that to get this right in general, we do need to implement the HTML5 > event model, which does have lots and lots of separate task queues. Do we have a bug for that? I couldn't find one.

We don't yet. Of course a first step is auditing the model (and all events it dispatches) to make sure it makes sense...

Bulk move to Toolkit::Notifications and Alerts Filter on notifications-and-alerts-component.