Hacker News Reader

Comment by BjoernKW | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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.

Reply on news.ycombinator.com