17

I'm considering adding an alert() to our Javascript utility assert function.

We're an ajax-heavy application, and the way our framework (Ext) implements ajax by polling for the ajax response with setInterval instead of waiting for readystate==4, causes all of our ajax callbacks to execute in a setInterval stack context -- and an exception/assert blowing out of it usually fails silently.

How does a low-level alert() impact the browser event loop? The messagebox by definition must allow the win32 event loop to pump (to respond to the mbox button). Does that mean other browser events, like future setIntervals generated by our framework, resize events, etc, are going to fire? Can this cause trouble for me?

IIRC: you can use Firefox2 and Firefox3.5 to see the difference I'm talking about.

alert('1');
setTimeout(function(){alert('2');}, 10);
alert('3');

Firefox3.5 shows 1-3-2. Firefox2[1] shows 1-2&3 (2 and 3 stacked on top of each other simultaneously). We can replicate 1-2&3 in IE8 with a win32 mbox launched from ActiveX as well, instead of an alert, which wreaked havoc on us back in the day, and I want to make sure we don't go down that path again.

Can anyone point me to specific low level resources that explain this behavior, what the expected behavior is here, and what exactly is going on at a low level, including why the behavior changed across Firefox versions?

[1] you can replicate this on Spoon.net which I can't get working right now. I just reproduced it in a VM with Firefox 2.0.0.20.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Dustin Getz
  • 21,282
  • 15
  • 82
  • 131
  • Excellent question. In my experience, the implementation of `alert` differs dramatically across browsers. In general, I would avoid `alert` where these things matter and use custom (i.e. jQuery UI-style) dialogs. – Oliver Moran Jun 07 '11 at 17:19
  • @Oliver -- yeah, we actually chose to use a DOM-based popup, but I still would like to understand the alert internals. – Dustin Getz Jun 07 '11 at 18:56
  • 1
    *“The messagebox by definition must allow the win32 event loop to pump”* – some operating systems — Mac OS X, for example – use nested event loops. An alert might run a [modal event loop](http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinPanel/Concepts/UsingModalWindows.html) of its own which blocks the main event loop. It’s likely that some web browsers do something similar for dialog boxes. – s4y Jun 08 '11 at 21:10

2 Answers2

7

First, timers in javascript are not very precise. Intervals smaller than 30ms might be considered all the same, and implementations vary. Don't rely on any implicit ordering.

An alert() will always halt the event loop. If an event or timer fires during the alert, they will be queued and called after the event loop resumes (the alert box is closed).

Take this example:

var hello = document.getElementById('hello')

setTimeout(function(){
  hello.style.backgroundColor = 'lime'
}, 5000)

alert('Stop!')

setTimeout(function(){
  hello.innerHTML = 'collaborate'
}, 20)

setTimeout(function(){
  hello.innerHTML = 'listen'
}, 1000)

There are two possible outcomes:

  1. You close the alert box in under 5 seconds. The two timers that follow will be set and fire at specified intervals. You can see that the event loop is halted because regardless of how long you wait to close the alert, "listen" will always take 1s to execute.

  2. You take longer than 5 seconds to close the alert. The first interval (bgColor) will have passed, so it executes immediately, followed by the two timers being set and called.

http://jsbin.com/iheyi4/edit

As for intervals, while the event loop is stopped it also "stops time", so in this case:

i = 0

setInterval(function(){
  document.getElementById('n').innerHTML = ++i
}, 1000)

setTimeout(function(){
  alert('stop')
}, 5500)

Regardless of how long you take to close the alert, the next number will always be 6 - the setInterval won't fire multiple times.

http://jsbin.com/urizo6/edit

Ricardo Tomasi
  • 34,573
  • 2
  • 55
  • 66
  • good points. `An alert() will always halt the event loop` well, at the minimum, the browser process's win32 message pump is processing wm_paint because it redraws if we move the mbox around. does setInterval wait in FF3+ because wm_timer's aren't processing, or is it because of some fancy interaction with the javascript vm? – Dustin Getz Jun 08 '11 at 20:52
  • @Dustin: the javascript event loop is obviously different from the win32 event queue (there's no implicit loop in win32). I'm pretty sure the WM_TIMERs are processed normally all the time, only the way in which the javscript timeouts are implemeted makes it appear different. – T-Bull Jun 08 '11 at 21:11
1

I haven't been able to replicate the 1-2&3 case, but here is a fiddle that may help you debug what is going on in the different browsers.

Briguy37
  • 8,342
  • 3
  • 33
  • 53