
Ask HN: Why do browsers still support pop up dialogs and other bad behavior? - twshoopboop
There are still malware and advertising sites out there that allow browsers to use modal dialogs (ie, you can&#x27;t interact with the page without answering the dialog). You can&#x27;t even close the tab without getting rid of the dialog. There are also sites that will kill your page history by going through a bunch of redirects to prevent you from leaving with the back button. Why are these kinds of things allowed and supported by web browsers? Why do they even need the ability to have a pop up dialog with modern web sites being what they are?
======
evmar
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.)

~~~
DonHopkins
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
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
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
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.

~~~
DonHopkins
Mind = blown!

This is comically terrible:

[https://msdn.microsoft.com/en-
us/library/ms536759(v=vs.85).a...](https://msdn.microsoft.com/en-
us/library/ms536759\(v=vs.85\).aspx)

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

------
stephenr
Safari has actually changed behaviour so alert/prompt/confirm dialogs are
_not_ modal outside of the tab - you can switch to other tabs and I believe
even close the window/tab.

They've also been restyled to make it obvious they're a prompt from the
website not from safari itself.

Also, there _are_ legitimate uses for this functionality, so as with many
things I think the solution is not to remove the functionality, just improve
the implementation.

~~~
cprecioso
> Safari has actually changed behaviour so alert/prompt/confirm dialogs are
> not modal outside of the tab - you can switch to other tabs and I believe
> even close the window/tab.

Firefox does this too.

~~~
jszymborski
[http://i.imgur.com/WIeUFTN.png](http://i.imgur.com/WIeUFTN.png)

~~~
schwap
... and now click on another tab.

~~~
jszymborski
[https://gfycat.com/HospitableGiftedGerenuk](https://gfycat.com/HospitableGiftedGerenuk)

------
JohnTHaller
> There are also sites that will kill your page history by going through a
> bunch of redirects to prevent you from leaving with the back button.

It's 2016 and Microsoft is incapable of creating a reliable cross-site login
system. Instead, we still have the disastrous mess that is live.com. Minimum 2
redirects - at least 1 of which is Javascript (seriously?) - to handle a
simple login. And when your cookies go a bit wonky, you won't even be able to
browser the MSDN site to look up technical details. You have to manually clear
your cookies. Again.

~~~
cm2187
2 redirect? A dozen at least. And one website for the login, another for the
password. Why do simple when one can write a piece of shit!

~~~
rblatz
In their defense based on your login it can push you to a different IDP to
authenticate. In practice it's bad form to MiTM passwords for other systems,
hence the password and login on different pages.

------
davegauer
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.com whatever resources it needed. But
clickbait-headline-slideshows.com could not, unless you explicitly allowed it.

~~~
wutbrodo
I just keep Javascript turned off except for sites I whitelist. Nobody ever
believes how easy and unobtrusive this is, despite browsing a pretty huge and
diverse set of domains.

This has gotten a little more difficult since chrome changed the UI around
these settings though.

~~~
joshbaptiste
I use uMatrix on Chrome and only allow certain things to run on various pages,
to only render the content I want.

------
BjoernKW
Quite simply because browsers are not just used for websites but as an
application platform as well. Depending on the design and the requirements of
an application modal dialogues and in rare cases even disabling leaving via
the back button absolutely make sense.

It might not amount to good UX practices but it's not malware or a dark
pattern either.

Besides, if at all possible most browser vendors try to be backward
compatible. There are many applications out there that make ample use of pop-
up dialogues. There's no need to break those just because they don't provide a
stellar UX.

~~~
twshoopboop
>Depending on the design and the requirements of an application modal
dialogues and in rare cases even disabling leaving via the back button
absolutely make sense.

Sorry, I disagree with you. On a typical non-web application, a modal dialog
doesn't prevent me from accessing other applications. It doesn't prevent me
from forcefully killing crapware either. The idea that web applications should
be able to break user expected control at the browser level is silly.

Browsers have Back, Forward, Refresh, Stop buttons, Tabs, cookie prefs, DNT
prefs etc. Anything contained in a browser should respect these things.
Browser devs should enforce this as browsers become more and more like their
own operating systems.

~~~
enraged_camel
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 override it or disable it. Sure, the user may
be confused/frustrated, but not as much as they would if they saw a double-
charge on their credit card statement.

~~~
sametmax
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.

~~~
dredmorbius
Such as HN on comment submission.

~~~
sametmax
Comments and charging for money don't have the same objectives at all. I can
understand that a dev can decide to allow the rare situation for rare
duplicate comment that you can easily delete because it saves work and is not
a big deal. While with other's people money, you can't do that. It's all a
question of balance.

~~~
dredmorbius
Solving one solves the other.

While I executed my QED here deliberately, I've left more than a few duplicate
comments on laggy connections and/or bogged-down browser sessions.

Other elements of HN's design and workflow make _detecting_ this difficult.
Rather than returning the user to the comment they'd just posted, or its
parent, you're returned to the discussion root.

Catching typos, incorrect tags (I keep having to remember that _this_ doesn't
emphasise content), etc., would be far easier if the renderd comment was
presented.

Solving this as a browser / HTML built-in would be most ideal.

HTML though isn't stateful. By design.

------
robbrown451
I don't have the answer but it seems like 90 percent of these could be solved
with a button on the browser (possibly in a drop down menu) that kills a tab
NO MATTER WHAT. Basically a force quit / kill -9 for a tab.

I don't see how any of the "excuses" in other people's comments would preclude
something like that allowing people to easily escape an evil site like you
describe.

------
pcwalton
Pages rely on window.open() for all sorts of non-popup things. You can't just
break window.open(), or sites like DDG will stop working.

Not that there aren't ways to fix this, but in general "remove the offending
API" rarely works on the Web. You need a more subtle approach.

~~~
t3nary
I think OP is rather talking about window.{alert,prompt,confirm}, at least
"ie, you can't interact with the page without answering the dialog" hints
towards that

~~~
pcwalton
That's tricky too. You can't just remove window.prompt, or users won't be able
to use pages that rely on it for critical input. So what do you do?
window.prompt is a synchronous API; you have to return _something_ to the code
that called it. You might say "well, just suspend that function and let the
user interact with the rest of the page". But by doing that you've introduced
coroutines to JavaScript (since "interacting with the rest of the page" means
"running JS"), which is a huge change that comes with a mountain of tricky
interactions. Even if it could be made to work (which most browser vendors
think is impossible), it would _still_ break pages that didn't expect random
state to change across the window.prompt call.

------
sandworm101
Don't assume that those in charge of browsers need only appease users. Who
makes browsers? Google, apple, microsoft... they have their own interests to
worry about. Firefox is an oddball, but even they have interests beyond users.

~~~
addicted
Firefox, unfortunately, also has to be consistent with what everyone else is
doing.

------
greggman
[https://bugs.chromium.org/p/chromium/issues/detail?id=456](https://bugs.chromium.org/p/chromium/issues/detail?id=456)

------
sklogic
Why only web? Modal dialogs should be forbidden everywhere.

~~~
joshuak
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 branching that the user can override later. Data is copy on
write, and versions are retained. Login is handled with PKI.

Modal is forbidden on our platform period. 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. We believe the user is the final
authority, not the programmer, or the platform.

(obviously this is a bit of a pet peeve for me)

~~~
DonHopkins
>"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.

------
hk__2
The fact that people make bad things with features doesn’t mean these features
are inherently bad. You’ll always have people abusing the technology. Pop up
dialogs are used a lot for e.g. form validation.

~~~
PeterisP
Preventing the bad things may easily be more valuable to users than
keeping/enabling the good things made possibly by that tech.

~~~
hk__2
Most browsers now let you stop alerts from a website, thus avoiding the `while
(true) { alert(…); }` variants.

~~~
hollerith
OK, _how_ does a user stop an alert? Pick a browser and explain.

~~~
hk__2
Chrome gives you a checkbox on the second alert on the same website to prevent
any future one. You can’t avoid the first two but you can avoid all the next
ones.

------
grogenaut
A major issue I haven't seen mentioned below is that for auth things like
paypal or other logins you need to show the root security context is from the
site you are authenticating to. You can do that by either moving the whole
window to the login page, which can be jarring and cause users to be confused,
or you can do a popup. Some sites choose one, some choose the other. When you
have active things going on on the first site, it really causes the drive to a
popup.

------
IvanK_net
There are much worse things that a website can do to your computer. Website
can run Javascript, which drains your CPU (drains your battery), it can use
your hardware e.g. to mine bitcoins while you are reading an article.

At the end of the day, I think it is not that easy to say, what is a "bad
behavior". Somebody can consider showing advertisment as a bad behavior. In
many cases you can communicate with authors of a website and tell them your
opinions, or stop wisiting that website (which is also a form of
communication, authors will know that something is wrong when they lose
visitors).

------
aboodman
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)

~~~
twshoopboop
Except my point is I'm completely okay with this because its not modal at an
application level if its HTML. I just want to be able to leave the site.
Change the way the page is rendered all you want, disable interactivity etc
but I don't feel a website should be able to prevent me from closing it which
is what a modal dialog does.

~~~
bryanlarsen
The most common use for onwindowunload dialog boxes is to warn the user of
unsaved changes and prevent their loss.

Our web app autosaves so the dialog box should never appear, but our metrics
show that it appears surprisingly often -- sometimes it can take a few seconds
for changes to flush through the websocket, and for the save to get
acknowledged.

If you took that away, our users would lose changes. I imagine they would get
pretty irate.

~~~
jessriedel
If this is absolutely necessary, you can force the site to request permission
to do this, just like getting location.

~~~
globuous
How about making it 'harder' for the user to close the browser when there is
an alert being shown by a website ? For instance, if google docs throws an
alert about the data not being saved, your browser could throw you a msgbox
notifying you that such tab has an alert you haven't dealt with when you try
to close it.

Yes, that's a lot of msgboxes, but it's a decent compromise I think. It's not
like that would happen very often anyway.

------
elliottcarlson
I personally am a big fan of the modal behavior when I receive notifications
of an upcoming meeting on my Google Calendar - having that screen come to the
front clearly grabs my attention, and allows me to prepare for whatever
task/call/meeting I have coming up.

------
xcombelle
I did not have such problem with firefox.

------
HannibalLecter
Vulnerabilities are patched frequently enough. If there is a kind of behavior
you want to prevent, write a plugin for it. Noscript and Greasemonkey are
pretty handy for most things.

The worst things a browser can do come from javascript, so having a whitelist
is useful. Remove anyone from your whitelist that is engaging in behavior you
disapprove of.

I don't let facebook run scripts on my machines because I disagree with their
philosophy of selling user data to the highest bidder, and tracking everything
users do. That's too intrusive so I simply disallow them access.

No site that calls in too many javascript packages is given any privs on my
computer.

