Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11) Reporter
	Description • 13 years ago

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.

	Justin Dolske [:Dolske]
	Comment 1 • 13 years ago

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?

	Justin Dolske [:Dolske]
	Comment 2 • 13 years ago

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

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11) Reporter
	Comment 3 • 13 years ago

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

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11) Reporter
	Comment 4 • 13 years ago

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?

	Boris Zbarsky [:bzbarsky]
	Comment 5 • 13 years ago

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.

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 6 • 13 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 7 • 13 years ago

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

	Matthew N. [:MattN]
	Comment 10 • 10 years ago

Bulk move to Toolkit::Notifications and Alerts

Filter on notifications-and-alerts-component.