undefined

points

[-]

There's a place for it within SPAs - you want the browser back button to retrace your path through screens in the application, not exit it, unless you are already on the first page. The same would be true for multi-page apps using HTMX or Turbo or something - if you change pages without doing a full page load, you need to push your new URL. The guiding principle is that the browser back button should work as the user expects - you should only mess with the browser history stack to fix any nonsense you did to it in the first place.

by phkahler10 hours ago|

parent|

[-]

>> There's a place for it within SPAs - you want the browser back button to retrace your path through screens in the application, not exit it, unless you are already on the first page.

No, You SPA should have it's own back button within the app. My browser back button should get me out of there no matter what.

by creatonez10 hours ago|

parent|

[-]

Then you lose the benefit of having the current URL actually linking to the resource you are currently viewing. If the app is not properly making use of URL modification and the history API, getting back to where you were requires navigating the whole maze each time.

by bevr13378 hours ago|

parent|

prev|

[-]

How could the user expect consistent behavior from the back button if web apps can no longer leverage it like web sites?

by SoftTalker7 hours ago|

parent|

prev|

[-]

I use a couple of web apps that have this. It's frustrating, because muscle memory has me clicking the browser back button instead of the back button in the app. So that probably takes me back to the front page of the app, or out of it entirely, which is not what I wanted at all.

by Sayrus12 hours ago|

prev|

[-]

On the other hand, "are you sure you want to exit without saving" is a good use-case. But I'd prefer that to be a setting I can allow for specific site.

by gwbas1c11 hours ago|

parent|

[-]

That API has quite a few heuristics that protect the user:

(At least on the Chromium browsers that I've tested it with)

1: It fails silently if the user hasn't interacted with the page. (IE, the user needs to "do something" other than scroll, like click or type.) This generally stops most SPAM.

2: The browser detects loops / repeated prompting and has a checkbox to get out of the loop.

---

It was a little jarring the first time I used that API and tested my code with it; but I appreciate the protections. I've come across far too many "salesman putting their foot in the door" usage of it.

by wat1000012 hours ago|

parent|

prev|

[-]

Better yet, just save. Storage is cheap and fast these days. The “do you want to save?” idiom is a leftover from the days when a moderately sized document would take a noticeable amount of time to save and eat up a decent chunk of your floppy disk.

by tripflag11 hours ago|

parent|

[-]

But what if you are leaving the page because you changed your mind, and don't wish to save the changes after all? This, for me, is the common case, so i would not want the browser to suddenly commit an unfinished draft.

by wat1000011 hours ago|

parent|

[-]

If you’re worried about losing the old version, it should keep a history. If you want to erase the new version, there should be an explicit action to do that.

by Sayrus10 hours ago|

parent|

prev|

[-]

An unfinished upload or sync stored locally instead of on the remote can absolutely be an issue. You can look at all the posts about OneDrive and GDrive not actually syncing before confirming to users who then delete their files since they "have been uploaded". Or the user may never open that specific page again or the session will not exist anymore when he comes back.

Browser storage is cheap, but it is not guaranteed to be durable.

by wat1000010 hours ago|

parent|

[-]

That's a good point. You'd want some (overridable) way to block navigating away until the sync completed, or do it in the background. Local storage is pretty easy, remote can get tricky.

by _fat_santa10 hours ago|

prev|

[-]

> are you sure you want to leave

I would argue there is a place for this in web-apps. For example I have a SaaS app and I employ this on any form pages where the user has already started to enter information in.

I have considered form persistence so in the event a user goes back to a previous page, realizes it's a mistake and goes forward again, their form state from the previous state is persisted.

But I would like to ask, what would users prefer the behavior be on a form page like this?

by lexicality7 hours ago|

parent|

[-]

That's fine, there's already an API for this: https://developer.mozilla.org/en-US/docs/Web/API/Window/befo...

That's very different to sites like tomshardware that pops up a "hey why don't you check out this extra slop you didn't ask for" when you try to navigate away

by encom9 hours ago|

prev|

[-]

Spawning a new tab is also hijacking the back-button, and should be disallowed completely. No exceptions. Opening a new tab, or god forbid a window, is messing with client software. Violations should carry a minimum 6 month jail sentence.

Pre-empting the web-mail comment: I know. I don't care.