Re: Strict mode callbacks and setTimeout

On 7/8/11 6:01 PM, Ian Hickson wrote:
>> That's unclear.  While there is only one task queue, the list of active
>> timeouts is per-window.
>
> Indeed. setTimeout also depends on the "fully active" state of the
> Document of its Window.

Ah, yes.  That part is important too.

> It means literally what it says, i.e. globally across the whole universe,
> within, of course, the limitations of the hardware.

That doesn't make much sense to me.  For example, it means that one tab 
that has posted a timeout and then went into an infinite loop should 
block timeouts in unrelated sites.

> This might be too strong a requirement, though. I'm happy to scope it somewhat if that would
> make more sense. Scoping it to the Window objects using the same event
> loop probably makes the most sense; would that be better?

I'm not sure it would be enough better.  As the spec is currently 
phrased, that would mean that a setTimeout(0) call on a background-tab 
window would delay a later setTimeout(0) call on a foreground window 
that is on the same event loop.  That somewhat defeats the point of 
throttling background windows.

What Gecko does right now is that the "if two timeouts are set for the 
same delay then the one that was set earlier should fire earlier" thing 
applies per-window.  That is, the list of timeouts for a window is 
stored in firing order, but nothing per se guarantees the relative 
ordering of timeouts in two separate windows.

In particular, in Gecko's current implementation if you have two windows 
A and B and then you perform the following actions:

  A.setTimeout(f1, 0);
  B.setTimeout(f2, 0);
  A.setTimeout(f3, 100);
  B.setTimeout(f4, 100);
  var start = new Date();
  while ((new Date() - start) < 1000) ;

and return to the event loop, then the firing order of the callbacks 
will definitely be either "f1, f3, f2, f4" or "f2, f4, f1, f3" (because 
we process all the "old enough" timeouts for a window before moving on 
to another window).  I suspect in this particular case we actually 
guarantee that it will be "f1, f3, f2, f4".  Attached is a testcase for 
this behavior using subframes.  In the case of Gecko that doesn't affect 
the results; any other two windows would give the same behavior.  This 
last claim may or may not be true for other browsers.

I just tested locally, and on my testcase Opera seems to produce "f1, 
f3, f2, f4" just like Gecko.  Safari, Chrome, and IE9 (in all modes) all 
produce "f1, f2, f3, f4".  Again, the behavior here may depend on 
whether things are in different tabs or not.  Worth checking with other 
implementors.

-Boris