Different tabs that share an origin can get references to each other using the return value of "window.open" or the value of "window.opener". There might be other ways as well. From there all bets are off as they can execute arbitrary code on each other's global scope.
This is strange: On the Mac, Chrome seems to block the execution of other tabs, but Firefox and Safari don't. Try opening each of these urls in different tabs, and press the button in one, switch to the other tab, and press the button in the other.
Chrome puts the alert in a separate window that stays on the screen when you switch tabs, and it queues the button press in the blocked tab until after you dismiss the alert from the other tab. Also, ctrl-tab doesn't switch tabs while an alert dialog is up, which sucks.
But Safari and Firefox don't block execution (which is how I expected it to behave), and they show the alert in a sub-window of the tab that's hidden when you switch tabs (which is what I greatly prefer, rather than having a loose alert window floating around with no way to tell which tab it's associated with and freezing).
Is there a spec that explicitly says browsers are actually supposed to block execution of JavaScript in tabs of the same domain, and are 2 out of 3 browsers I just tested breaking that spec?
How does it work on other browsers and other platforms?
Apparently Chrome considers sub-domains to also block JavaScript execution:
I am astonished by Chrome! I don't like those loose blocking alert dialog windows and disabled tabs at all. If I'd noticed that behavior in the wild, I would have reported it as a terribly unfortunate bug.
Most of HTML's behaviors are "specced" in the sense that the WHATWG sat down and documented the behaviors of Internet Explorer and Netscape that they witnessed sites out in the wild depending on.
On Windows Chrome, your demo pages block the entire browser, including other windows. Windows Chrome has had the most attention paid to "old" web compat.
When we were making Linux/Mac Chrome I remember a point where we were looking at porting the cross-process lock functionality and similarly wondering "what site could ever need this". I remember punting the bug to implement this for quite a while; I'm not certain it ever got fixed.
If you wanna have your mind blown along these sorts of crazy web behaviors, you should look up the semantics of the "showModalDialog" browser API, and also the many people who were upset about Chrome's recent removal of it.
>Neither modal nor modeless HTML dialog boxes support text selection or the standard shortcut menu for copy operations; however, you can imitate this functionality by using script with TextRange objects and event handlers for onmousedown and onmousemove, ...
