As usual, it's a good first step but doesn't go far enough. I don't want my back-button hijacked by _anything_.

My issue with back-button hijacking isn't even spam/ads (I use an ad-blocker so I don't see those), but sites that do a "are you sure you want to leave? You haven't even subscribed to our newsletter yet?!"

▲

NoGravitas 3 hours ago | parent | next [-]

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.

▲

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

	▲	creatonez 2 hours ago \| parent \| next [-]
		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.
	▲	bevr1337 39 minutes 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?

▲

_fat_santa 2 hours ago | parent | prev | next [-]

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

▲

Sayrus 5 hours ago | parent | prev | next [-]

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.

▲

gwbas1c 3 hours ago | parent | next [-]

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.

▲

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

▲

tripflag 4 hours ago | parent | next [-]

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.

	▲	wat10000 4 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.

▲

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

	▲	wat10000 2 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.

▲

encom 2 hours ago | parent | 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.