Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#61

Post by DonHopkins »

caylus wrote: post #59
DonHopkins wrote: post #58

Earlier quoted context omitted.

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. Whe…

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.

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.

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#62

Post by DonHopkins »

joshuak wrote: post #53
sklogic wrote: post #44

Why only web? Modal dialogs should be forbidden everywhere.

Oh god yes! Worst invention EVER. Modal dialogue boxes are for lazy programming not for UI. Almost nothing in real life is modal. Don't break a user's flow! We just built a full application platform (i.e. dev kit, apps, application environment, etc.) and nothing is model, not one thing. Errors are added to a notification list that a user can look at at any time. Data merge conflicts are resolved via automatic default…

>"If an app breaks this some how and finds a way to hack a modal event, we will treat this as a DOS attack and remove the app and ban the developer."

I like the cut of your jib!

I wholeheartedly agree: modal dialogs are demon spawn. A throwback to the single-threaded Mac that freezes the entire operating system even while you have a menu popped up.

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#63

Post by evmar »

DonHopkins wrote: post #61
caylus wrote: post #59

Earlier quoted context omitted.

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. 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…

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.

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#64

Post by chongli »

evmar wrote: post #15

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…

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.

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#65

Post by dredmorbius »

davegauer wrote: post #32

I sometimes wonder how nice life would be if we had two modes in browsers: Mode 1: Render static content; allow unobtrusive JavaScript operations (perhaps capped by total operations or CPU usage). Mode 2: Run unlimited JS operations, allow alert() and window.onbeforeunload events handers. The second mode could be called "Application Mode" and could be turned on selectively per site. This would allow you to give gmail…

I've seen call for a four-way split of browser functionality.

1. Reading/commenting mode. 2. Applications 3. Commerce. 4. A/V media.

The're four distinct use cases, with four distinct client requirements (and/or isolation requirements).

uMatrix buys you some of the JS isolation you're looking for.

https://www.reddit.com/r/dredmorbius/comments/256lxu/tabbed_...

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#66

Post by dredmorbius »

sametmax wrote: post #24
enraged_camel wrote: post #22

Earlier quoted context omitted.

Disabling the back button can be very useful in certain scenarios. Sometimes you want to prevent users from shooting themselves in the foot, for example when submitting a credit card payment. Even though there are prominent "please do not use the back button!" warnings, a lot of users still do, resulting in double-charging. So clearly there are scenarios where the default behavior can be sub-optimal and you need to o…

If you don't use a one-time generated key for the paiement page, one that can't be reused, and a process queue, you are doing it wrong. This is a technical problem, your user should not have to bother about thinking if can reload the page of not, he/she should be able to murder the shit of the F5 boutons if he/she wants to.

Such as HN on comment submission.

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#67

Post by dredmorbius »

sametmax wrote: post #24
enraged_camel wrote: post #22

Earlier quoted context omitted.

Disabling the back button can be very useful in certain scenarios. Sometimes you want to prevent users from shooting themselves in the foot, for example when submitting a credit card payment. Even though there are prominent "please do not use the back button!" warnings, a lot of users still do, resulting in double-charging. So clearly there are scenarios where the default behavior can be sub-optimal and you need to o…

If you don't use a one-time generated key for the paiement page, one that can't be reused, and a process queue, you are doing it wrong. This is a technical problem, your user should not have to bother about thinking if can reload the page of not, he/she should be able to murder the shit of the F5 boutons if he/she wants to.

Such as HN on comment submission.

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#68

Post by dredmorbius »

sklogic wrote: post #44

Why only web? Modal dialogs should be forbidden everywhere.

I particularly like the model Ello came up with for some destructive confirmations (delete / cancel post, etc.)

A full-screen, in page overlay, in red, with a clear, black-on-white dialog stating what you were about to do and requesting confirmation.

It's obvious. It's user-centric. It doesn't affect other browser tabs. And they don't abuse it for other functions (nags, etc.).

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#69

Post by dredmorbius »

aboodman wrote: post #8

It's not possible to prevent applications from creating modal dialogs and still allow them to be usefully interactive. If you took away `alert` and friends, sites would (and do) just create dialogs with HTML instead. If you want websites to be able to be dynamic at all, then they can use that power to be annoying. Two sides of the same coin. (the history thing seems like it might be more addressable)

See: https://news.ycombinator.com/item?id=11747335

Re: Ask HN: Why do browsers still support pop up dialogs and other bad behavior?

#70

Post by DonHopkins »

evmar wrote: post #63
DonHopkins wrote: post #61

Earlier quoted context omitted.

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/tab2.html Chrome puts the alert in a separate window that stays on the screen when you switch tabs, and it…

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…

Mind = blown!

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, ...

Post reply on HN