261–270 of 532 posts
Some Microsoft sites have been very guilty of this. They are the ones that stick in my head in recent memory.
IIRC the Azure “portal” does this. Also likes to not record things as navigation events that really feel like they should be. Hitting back on that thing is like hitting the back button on Android, it’s the “I feel lucky” button. Anything could happen.
This seems like a good time to advertise the post/redirect/get pattern. https://en.wikipedia.org/wiki/Post/Redirect/Get Not strictly about hijacking back navigation but it can make experience less bumpy if you've got form submissions in the middle of the path.
I understand this is vague on purpose but wish there was more detail. E.g., if I am running a game in a webgl canvas and "back button" has meaning within the game UI which I implement via history states, is my page now going to be demoted? This article doesn't answer that at all.
If it automatically adds something to the history when you visit the page, then yes. If it only adds to the history when the user clicks something, then I would assume it would be fine. Hopefully.
Earlier quoted context omitted.
There are valid use cases however the issue is rooted in lacking browser APIs. For instance, - if you want to do statistics tracking (how many hits your site gets and user journeys) - You have a widget/iframe system that needs to teardown when the SPA page is navigated away - etc The browser does not have a; globalThis.history.addEventListener('navigate') So you must monkey patch the history API. It's impractical fro…
Browsers now have window.navigation.addEventListener("navigate") that allows just this. https://developer.mozilla.org/en-US/docs/Web/API/Navigation/...
Earlier quoted context omitted.
> This relates to Chrome, not to search. To me, it appears to relate to search > Pages that are engaging in back button hijacking may be subject to manual spam actions or automated demotions, which can impact the site's performance in Google Search results.
Good point. Chrome has a “feature” where if your website is google-flagged, it’ll display a danger alert when visiting it. For some reason I confused that with this.
Earlier quoted context omitted.
If the navigation simulates what would happen if we follow links to SPA#pos1, SPA#pos2, etc so that if I do two clicks within the SPA, and then hit Back three times I'm back to whatever link I followed to get to the SPA, I guess it's OK and follows user expectations. But if it is used as an excuse to trap the user in the SPA unless they kill the tab, not OK.
From the browsers perspective those are the same thing though. It’s a paradigm boundary. The real answer is to have desktop applications that work like applications (buttons do what feels right), and websites that work like websites. SPA, is a page application. Pages aren’t applications, applications aren’t pages. AutoCAD is an app, the Robotech Encyclopedia is content.
If the browser only allows adding at most one history item per click, I should be able to go back to where I entered a given site with at most that many back button clicks.
At a first glance, this doesn't seem crazy hard to implement? I'm probably missing some edge cases, though.
A browser feature I wasn't aware of for too long: long press the back button, to get a list of recent URLs, allowing you to skip anything trying to hijack the back button.
That’s surely bounded now much it can show, so an attacker can just fill it up till the api throws an error
Earlier quoted context omitted.
i love it. my mac doesn't have the home row (don't know if that's how that row of buttons is called) so I use spacebar and shift+spacebar as pgdown and pgup when I am reading
[fn]+[up arrow] = pgup, [fn]+[down arrow] = pgdown, [fn]+[left arrow] = home, [fn]+[right arrow] = end
> Notably, some instances of back button hijacking may originate from the site's ... advertising platform I feel like anything loaded from a third party domain shouldn't be allowed to fiddle with the history stack.