5 ms·

The other answers given give the high-level view, but one technical detail to add: the semantics of alert() are that it blocks the execution of JavaScript. In

by evmar 10y ago

The other answers given give the high-level view, but one technical detail to add: the semantics of alert() are that it blocks the execution of JavaScript. In old browsers that means across all tabs because that was how they were implemented. Modern browsers are capable of running separate JS contexts, but doing so breaks backwards compatibility in a corner case: if you have the same domain open in two tabs, an alert() on one should block processing in the other. Otherwise, interacting with the other could change shared JS state while the code assumed it was blocked. Concerns about this led to many discussions about designs where you would need to mark all tabs that were grouped together into blocks waiting for the modal to close, which are very difficult for users to understand. (I never quite understood why this hypothetical race was such a worry but people who knew more about web compat than me said that it was actually important, that sites relied upon this.)

vonklaus 10y ago
Is there a way to use this to forcibly eliminate javascript execution on some pages? If you ran a shadow dom, or background tab of some maliscious site, and forced an alert() on the page, could you then (in another context tab) run the page. It wouldn't make a lot of sense in practicality, but would be interesting to use alert() to block js execution, or even some of these olders legacy feature sets.
DonHopkins 10y ago
Since when did two different tabs opened on the same site share any JavaScript interpreter state, or block each other when showing modal dialogs? 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?
- caylus 10y ago
  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.
  - DonHopkins 10y ago
    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. http://donhopkins.com/home/tab1.html http://donhopkins.com/home/tab1.html http://donhopkins.com/home/tab2.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/tab1.html http://www.donhopkins.com/home/tab2.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.
    - evmar 10y ago
      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.
chongli 10y ago
but doing so breaks backwards compatibility in a corner case So why don't we make the tradeoff and break these corner case websites in order to fix a far worse problem? Backwards compatibility > * is too high of a standard.

by evmar 10y ago

vonklaus 10y ago

Is there a way to use this to forcibly eliminate javascript execution on some pages? If you ran a shadow dom, or background tab of some maliscious site, and forced an alert() on the page, could you then (in another context tab) run the page. It wouldn't make a lot of sense in practicality, but would be interesting to use alert() to block js execution, or even some of these olders legacy feature sets.

DonHopkins 10y ago

Since when did two different tabs opened on the same site share any JavaScript interpreter state, or block each other when showing modal dialogs? 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?

caylus 10y ago
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.
- DonHopkins 10y ago
  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. http://donhopkins.com/home/tab1.html http://donhopkins.com/home/tab1.html http://donhopkins.com/home/tab2.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/tab1.html http://www.donhopkins.com/home/tab2.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.
  - evmar 10y ago
    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.

chongli 10y ago

but doing so breaks backwards compatibility in a corner case So why don't we make the tradeoff and break these corner case websites in order to fix a far worse problem? Backwards compatibility > * is too high of a standard.