[merelysounds]

Looks like there is also a client side solution for that, at least in Firefox; it's possible to prevent a page from modifying browser history:

> Open the about:config page in Firefox

> Search for "pushstate"

> Double-click "browser.history.allowPushState"

source: https://superuser.com/a/1688290

[pfg_]

Usually when I see this from non-spam sites, it's not even pushstate, it's just some page that redirects as soon as it loads. So you press back twice and it goes back -> forwards -> back -> forwards. Disabling pushstate doesn't fix that, it just makes pushstate equivalent to a redirect.

[fluoridation]

That's relatively easy to work around. Right-clicking on the back button lets you go back several steps at once. I don't know about Chrome, but it does work on Firefox.

[HappMacDonald]

AFAICT just holding left-click for half a second has the same effect. That's been my go to since the little triangle dropdown vanished from the back button (checks watch).. uh, some time in the nineties mebe?

[int0x29]

Firefox had it in 2010. I don't remember when IE ditched it.

[chmod775]

I haven't had that problem in a while. Did browser vendors already do something about it?

[hansvm]

On qutebrowser I type 2H instead of H, and it doesn't go to the most recent history item at all. Mostly though, no, spammy websites still do this, and browser's haven't fixed it.

[mrandish]

Browser.history.allowPushState was deprecated in Firefox V47 (2016) once they'd restricted the ability of sites to muck with history state via JS. This used to be a pretty big issue but as a daily Firefox user for 20 years, sites changing history state hasn't been a problem in recent memory, so whatever they did works pretty well.

But the TFA is about a related issue with a similar symptom, hijacking (or disabling) the back button in Chrome browser. This also hasn't been an issue in Firefox in recent memory (kind of shocked to learn it still was until now in Chrome). However, I did have a problem in recent years in Firefox with sites hijacking the Browser_Back keycode and/or hotkey (keycode 166 or Alt+Left Arrow) but I solved it with a small UserScript I posted elsewhere in this thread.

I rarely click the back arrow icon on the interface since I have a three-finger tap on my touchpad assigned to send the Browser_Back keycode when the active window is Firefox. Being a keycode, this can be intercepted by site JS. While sites intercepting Browser_Back (keycode 166) is rare, some video players use the arrow keys to skip forward/back and Alt+Arrow to skip more. Since Firefox uses Alt+Left Arrow as the back hotkey, this can be an issue. I fixed it with a UserScript that prevents sites from blocking certain keycodes. Note: you can also change all Firefox's hotkeys by going to "about:keyboard".

[ohnoesjmr]

What about SPAs tho? Some of the state is in the URL, and as the user fills the form, you might push state to undo last step of the form. Does this mean that in this context the user gets thrown to about:blank? That would break tons of websites.

[mrandish]

I use all kinds of web apps and forms and have no issues with undo or other features. And the changes Firefox made to prevent malicious JS changing browser history were done in 2016. I don't think it has anything to do with undo within a page and I wouldn't expect the browser back button to replicate undo (ctrl + z).

As for my small UserScript, it has nothing to do with browser history state. It simply forces web site JS to share certain key strokes with my browser, add-ons and scripts instead of swallowing them (and it's easy to include/exclude any site or page).

[SquareWheel]

Single Page Applications use the History API to create a working back/forward history within the SPA. This will cause you to navigate away on use, and potentially lose data.

[HappMacDonald]

Why don't they just use # hash urls for their in-SPA page urls instead? That's what Elm and Elixir LiveView both do.

[joquarky]

That sounds like a design failure.

[SquareWheel]

Well, yes, but that's why it's behind an about:config flag and users should not enable it without understanding its effects.

[DangitBobby]

It's not, I don't know why you'd think that.