9 ms·
Ask HN: Why do browsers still support pop up dialogs and other bad behavior?
There are still malware and advertising sites out there that allow browsers to use modal dialogs (ie, you can't interact with the page without answering the dialog). You can'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?
- greggman 10y agohttps://bugs.chromium.org/p/chromium/issues/detail?id=456 https://bugs.chromium.org/p/chromium/issues/detail?id=456
- BjoernKW 10y agoQuite 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 10y ago>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 10y agoDisabling 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 10y agoIf 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 10y agoSuch as HN on comment submission.
- sametmax 10y agoComments 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 10y agoSolving 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.
- stephenr 10y agoSafari 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 10y ago> 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 10y agohttp://i.imgur.com/WIeUFTN.png http://i.imgur.com/WIeUFTN.png
- schwap 10y ago... and now click on another tab.
- jszymborski 10y agohttps://gfycat.com/HospitableGiftedGerenuk https://gfycat.com/HospitableGiftedGerenuk
- spatulon 10y agoChrome did this when it originally shipped, by rendering each tab in its own Windows desktop (in the same way that the lock screen is a separate desktop). For some reason they removed that functionality, and dialogs are now modal across all tabs.
- ryanbertrand 10y agoThis is also the way prompts happen on mobile Safari and iOS.
- sandworm101 10y agoDon'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 10y agoFirefox, unfortunately, also has to be consistent with what everyone else is doing.
- HannibalLecter 10y agoVulnerabilities 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.
- aboodman 10y agoIt'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 10y agoExcept 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 10y agoThe 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 10y agoIf this is absolutely necessary, you can force the site to request permission to do this, just like getting location.
- bryanlarsen 10y agoGoogle docs and Gmail and many other top 100 sites use on window unload. It wouldn't fly.
- globuous 10y ago
- JohnTHaller 10y ago> 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 10y ago2 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!
- JohnTHaller 10y ago2 redirect minimum. I've seen quite a few more. The most I've seen in my history was 3 or 4, though.
- rblatz 10y agoIn 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.
- douche 10y agoFlying Spaghetti Monster help you if you have both a personal and an organizational (Office 365) Microsoft account with the same email address.
- r3bl 10y agoFor those of you who don't know, the process basically goes like this: Input your email / password -> select if you want to use your personal or business profile -> enter your login info again (because, reasons) -> go through two redirects.
- pcwalton 10y agoPages 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 10y agoI 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 10y agoThat'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.
- ben0x539 10y agoIt'd be cool if window.open() just took some screen real-estate from the calling page, tho, instead of letting some content escape the shackles of its tab.
- evmar 10y agoThe 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 agoIs 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 agoSince 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 agoDifferent 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.
- hk__2 10y agoThe 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.
- davegauer 10y agoI 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.
- deleted 10y ago[deleted]
- wutbrodo 10y agoI 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 10y agoI use uMatrix on Chrome and only allow certain things to run on various pages, to only render the content I want.
- dredmorbius 10y agoI'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_browsing_a_lousy_bandaid_over_poor_browser/ https://www.reddit.com/r/dredmorbius/comments/256lxu/tabbed_...
- jstewartmobile 10y agoPreach on my brotha! I wrote up a similar proposal a few months ago, didn't get much love: http://www.eggplant.pro/blog/proposal-safeweb/ http://www.eggplant.pro/blog/proposal-safeweb/
- robbrown451 10y agoI 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.
- sklogic 10y agoWhy only web? Modal dialogs should be forbidden everywhere.
- joshuak 10y agoOh 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 10y ago>"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.
- dredmorbius 10y agoI 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.).
- Tharkun 10y agoI agree, but I can't really articulate why. Does anyone have a good list of reasons? I'd love to eliminate modal dialogs in the application we're building.
- grogenaut 10y agoA 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 10y agoThere 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).
- elliottcarlson 10y agoI 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 10y agoI did not have such problem with firefox.