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?
83 comments
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.)
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.)
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?
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?
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.
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.
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.
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.
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, ...
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, ...
You are referring to "popups" (that is, if a site by itself opens a new window/tab, not if you open a link in a new tab).
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.
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.
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.
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.
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.
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.
> 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.
Firefox does this too.
Chrome 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.
This is also the way prompts happen on mobile Safari and iOS.
> 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.
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.
The most infuriating thing is that when logging on to live.com or its friends, they hook the tab key. When you type in your email, then tab over the next field, it redirects underneath you.
This infuriates me. It also really screws with people who can't touch type, and thus don't realize it's happened until they look up after entering their password only to realize the page changed and their text was lost.
I presume what's going on is the site realizes the login won't work and redirects you to the domain where it will, but it's just terrible design all around.
This infuriates me. It also really screws with people who can't touch type, and thus don't realize it's happened until they look up after entering their password only to realize the page changed and their text was lost.
I presume what's going on is the site realizes the login won't work and redirects you to the domain where it will, but it's just terrible design all around.
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!
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.
2 redirect minimum. I've seen quite a few more. The most I've seen in my history was 3 or 4, though.
Flying Spaghetti Monster help you if you have both a personal and an organizational (Office 365) Microsoft account with the same email address.
For 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.
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.
Until very recently, Comcast/Xfinity did something similar. On their landing page and logged out, one would click log in and enter their credentials, and the top bar shows you logged in. Click on the email link and you have to log in again. Click on the "My Account" link and log in again not once but twice, for a total of three logins to finally get there.
I think they fixed it about a month ago. I have my Comcast email forwarded to a real account on a domain I own so I never have to use their insane email system again, but I still have to log in to pay my bill. It's down to one login session now, but it's still a nightmare of a site to navigate.
I think they fixed it about a month ago. I have my Comcast email forwarded to a real account on a domain I own so I never have to use their insane email system again, but I still have to log in to pay my bill. It's down to one login session now, but it's still a nightmare of a site to navigate.
HSBC's internet banking website is complete shit too. At least 2 redirects to login, and if you change your mind, the back button breaks the site completely until you manually go to the root again.
I appear to have a cookie set or something which makes the root of HSBC's site consistently 500 for me. At least the login still works.
Can't you pay by phone? That's how I deal with it on Optimum.
And if you're in some half logged in state it'll try to log you in to read public documentation, fail, and tell me a kb article is 404. I just use incognito mode, but have to go back to the google search first, as the new url is also broken. I swear they do stuff to make Chrome screw up, used to be that MS support pages didn't scroll properly in other browsers.
Meanwhile, Google authentication -- which begins at accounts.google.com -- often bounces through appengine.google.com, accounts.youtube.com, and other domains. Making apps for schools, it can be a bit dodgy explaining that the school needs to whitelist a YouTube url in order to use Google SSO.
Yes, I have always wondered why this happens the way it does. I haven't experiences being redirected through them, but it seems that on logon one is being randomly selected. They all are in the same 216.58.212.* subnet (now and here) but each have distinct IP-pairs.
Might it be some attempt to disspel censorship, such as the scenario you're describing?
On a slightly related note, I really hate that we Internet Citizens are convicted to using plaintext server name indication.
Might it be some attempt to disspel censorship, such as the scenario you're describing?
On a slightly related note, I really hate that we Internet Citizens are convicted to using plaintext server name indication.
Isn't it for setting cookies not on the google.com domain?
I believe that's because they use some variant of OAuth for authentication, which necessarily involves "a bunch of redirects".
https://en.wikipedia.org/wiki/OAuth
https://en.wikipedia.org/wiki/OAuth
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.
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.
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.
This has gotten a little more difficult since chrome changed the UI around these settings though.
I use uMatrix on Chrome and only allow certain things to run on various pages, to only render the content I want.
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_...
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_...
Preach 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/
I wrote up a similar proposal a few months ago, didn't get much love: http://www.eggplant.pro/blog/proposal-safeweb/
[deleted]
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
But why do you need to disable the back button? The issue in question (not resubmitting a credit card payment) could better be handled by the website telling the browser "Hey, this is a one time request".
Hitting the back button then does not lead to that request being sent.
I feel this is an issue where the heavy lifting should be done by website and browser devs, instead of breaking something the user expects.
Hitting the back button then does not lead to that request being sent.
I feel this is an issue where the heavy lifting should be done by website and browser devs, instead of breaking something the user expects.
That is an indicator of a seriously outdated form implementation.
I'm not sure I agree that no one should be able to disable the back button, but....there should be a user option to override it. A "no really I mean it I want to GTF off of this page now" button or option.
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.
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.
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.
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.
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
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.
It'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.
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.
Firefox, unfortunately, also has to be consistent with what everyone else is doing.
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 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)
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)
>"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.
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.
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.).
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.).
I 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.
Very few events really deserve to grab users attention in such a brutal way.
In fact, I cannot name a single one. Open/save file dialogue? Emacs minibuffers are light years ahead of the current Windows crap.
Asking for credentials? Same thing, only grey out the controls that directly depend on credentials and use something like emacs minibuffer for entry, not a new window on top of the rest of the form.
And, while I'm still on it - don't EVER grey out anything without an explanation. I want to be able to hover over a greyed out control and see a detailed explanation immediately. Not doing this is rude.
If a UI designer cannot build a seamless handling of all the exceptional cases into a flow, he'd better move on to a simpler job (I don't know - programming, sweeping streets, packing groceries, whatever) and let the professionals do the work instead.
Also, most (if not all) frameworks implement modal dialogues in a very ugly way. For example, in Visual Studio it is a very often case when you may want to copy and paste something from some other editor window into a modal dialogue. But you cannot - it's all locked! Such things are extremely annoying and totally unacceptable.
In fact, I cannot name a single one. Open/save file dialogue? Emacs minibuffers are light years ahead of the current Windows crap.
Asking for credentials? Same thing, only grey out the controls that directly depend on credentials and use something like emacs minibuffer for entry, not a new window on top of the rest of the form.
And, while I'm still on it - don't EVER grey out anything without an explanation. I want to be able to hover over a greyed out control and see a detailed explanation immediately. Not doing this is rude.
If a UI designer cannot build a seamless handling of all the exceptional cases into a flow, he'd better move on to a simpler job (I don't know - programming, sweeping streets, packing groceries, whatever) and let the professionals do the work instead.
Also, most (if not all) frameworks implement modal dialogues in a very ugly way. For example, in Visual Studio it is a very often case when you may want to copy and paste something from some other editor window into a modal dialogue. But you cannot - it's all locked! Such things are extremely annoying and totally unacceptable.
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.
Preventing the bad things may easily be more valuable to users than keeping/enabling the good things made possibly by that tech.
Most browsers now let you stop alerts from a website, thus avoiding the `while (true) { alert(…); }` variants.
[deleted]
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.
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).
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).
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)
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)
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.
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.
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.
If this is absolutely necessary, you can force the site to request permission to do this, just like getting location.
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.
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.
Google docs and Gmail and many other top 100 sites use on window unload. It wouldn't fly.
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.
I did not have such problem with firefox.
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.
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.