It appears that two setTimeouts such as: setTimeout(foo, 10); setTimeout(bar, 20); may fire out of order and cause 'foo' to be called after 'bar'. See https://bugzilla.mozilla.org/show_bug.cgi?id=547801#c4

That's an [orange] bug, BTW.

setTimeout is a DOM thing, though this might be an XPCOM timer issue before we're done!

We have code in nsGlobalWindow to ensure that in this situation the latter setTimeout will in fact fire later, no matter what the XPCOM timers do, no? So I don't quite see how this situation could arise.

nsGlobalWindow::InsertTimeoutIntoList() seems to store the timeouts in the order in which they should fire, so you're probably right. Bug 547801 comment 4 is probably mistaken then, so I'll mark this invalid unless/unless we find more compelling evidence to the contrary.