> 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 wo…
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!
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…
>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 ex…
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.
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…
If this is absolutely necessary, you can force the site to request permission to do this, just like getting location.
Google docs and Gmail and many other top 100 sites use on window unload. It wouldn't fly.
>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 ex…
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.
>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 ex…
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…
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.
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.
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.
> 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 wo…
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!
2 redirect minimum. I've seen quite a few more. The most I've seen in my history was 3 or 4, though.
> 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 wo…
Flying Spaghetti Monster help you if you have both a personal and an organizational (Office 365) Microsoft account with the same email address.
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…
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.