I've never liked calling it "History API" it's more focused on modifying what the back button will do.
It exists primarily to support SPAs that have hard links for different specific resource views but never actually navigate the user off the single page - the History API allows these sites to drop some breadcumbs so that users can return to different visual states they observed on their screen while never actually navigating....
That all said - I think there are much better ways to accomplish this using, I believe (it's been a bit) location.Url updates that cause micro-reloads... however if your webapp is a 300 pound gorilla this approach is significantly less appealing due to the obvious breaks in user flow.
I think the biggest problem with SPAs is trying to put them in a web browser. So many compromises we make just to use a technology that wasn't designed with the idea that you'd build an interactive app on top of it.
I don't know the solution, but I wish I could get a normal web, and then have a dedicated generic app sandbox that I can point at a particular app on the 'net.
Yep... most of the tracking and privacy issues exist, because browser expost too much apis to websites, many of those things not really needed for sites to work properly.
Hate to tell you, some form of this has existed for over 20 years. Once there was .back(), it’s been possible to pollute and corrupt browsing history. Even before the hashchange event, it was just a matter of polling the current state to detect history changes. The current API was designed to limit obvious abuse, but obvious abuse was already rampant and already too late to deprecate.
Didn't work for me though on Chrome or Slimjet. Worked in Firefox!
On Chrome based browsers, I see this error -
[Report Only] Refused to load the script 'https://ryanseddon.com/dist/app.bundle.js' because it violates the following Content Security Policy directive: "script-src 'self' 'sha256-MdC6fOvaO+dJENLQhOoRht9sHSJ++GoMxjtC5lOpUww=' 'strict-dynamic' https: 'unsafe-inline' 'report-sample'". 'strict-dynamic' is present, so host-based whitelisting is disabled. Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
Huh...so you can add a third-party domain to the history? That seems like a security flaw. I would have imagined you could only add history for the current domain.
Most sites (IME) do it by accident. The API as designed is a footgun, so much so that there’s an active proposal which would basically replace it. (I can’t speak to how much better the replacement might be.)
Obviously it can be used intentionally to hijack your session history, but it’s also surprisingly easy to do by mistake unless your state management is effectively designed for concurrency (which the API isn’t, but it encourages the same kinds of bad patterns).