Actually, I can answer that: JavaScript has run-to-completion semantics (everywhere it's implemented, not just Gecko) dating back to Brendan Eich's sleepless nights at Netscape, meaning that you can't have simultaneous script actions running -- a previous action must complete before another can be done or coherency goes out the window.
If you're in an environment where every tab is a renderer instance independent of every other, then this doesn't matter, because every renderer instance has its own independent JavaScript environment and coherency is unimportant between the instances. This is classically associated with Chrome, but Gecko could even do this until 2.0 with native embedding (the most famous examples being Camino and K-Meleon, both undone when this feature was removed {IMHO ill-advisedly}).
However, XUL is content just like HTML, and Firefox and friends going back to the earliest days of XUL in Mozilla 0.mumble use JavaScript to interact with it. This allows some very powerful scripting and extension capabilities, but since browser tabs are just constructs within an overall XUL framework which a single rendering instance manages, the browser's chrome and the website's content must essentially cooperatively multitask with a single JavaScript VM. If content does a long or slow operation, then chrome has to wait (which is why the timeout dialogue was implemented, in C++).
For a time Mozilla was looking at allowing chrome its own thread so that the browser chrome wouldn't be bogged down by a slow content script, but this had a lot of limitations to keep it compatible with the existing model (see
https://bugzilla.mozilla.org/show_bug.c ... upersnappy
). They're now trying to resurrect the old Electrolysis multiprocess model, but I've heard that song before years ago. While Mobile Firefox uses a form of this, it sacrificed a lot of compatibility to make it possible, and I don't think that will be acceptable on the desktop.