They share cookies, sure, but that's a very different thing that JS interpreter state.
But I've never heard anything about an alert in one tab blocking the JS interpreter of another tab on the same site, as that would certainly break the principle of least astonishment. Where is that behavior documented?
http://donhopkins.com/home/tab1.html
http://donhopkins.com/home/tab2.html
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:
http://www.donhopkins.com/home/tab1.html
http://www.donhopkins.com/home/tab2.html
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.
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.
This is comically terrible:
https://msdn.microsoft.com/en-us/library/ms536759(v=vs.85).a...
>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, ...