2

I have a single-page application (SPA) alongside several static pages. Whenever a state changes, the URL reflects the SEO/sharing-friendly details-page URL instead of the overview page with a parameter indicated currently-selected product (customer's requirements - not mine). So onbeforeunload I add a hashed URL just for the sake of proper history manipulation - so that when the user visits another page and then hits "back", they come to the SPA n its previous state with the SEO-friendly URL isntead of the hashed URL. Nothing was working in Chrome, so I checked out the other browsers. Only Firefox and Safari for Mac seem to handle everything the way I want, and Chrome and IE11 not. I know Safari throws a popState Event at every page load, which may or may not be the reason it works well.

In any case, I've worked up a very simple example here: http://miketheburns.com/test/js-history/index.html

You can see how the SPA is intended to work: I can click on products to open up their detail views and the detail URL changes in the URL bar. When I go to another page and then use the history back button, everything's fine because I replaced the history state to a hashed version onbeforeunload and revived the proper URL after the page load. But if you then use the browser forward button, then back again, the hashed version isn't called, but the detail version (which throws 404 in my example). Either the hashed version is skipped or not loaded at all, I'm not sure.

Is this a "bug" with Chrome/IE, or a "feature" in that they try to predict the history for me instead of letting me set it?

And before this is marked duplicate of How to cope with refreshing page with JS History API pushState, I'd just like to say "I know it's not best practice to push a state which doesn't 1:1 reflect the actual state of the application, but it definitely should be possible, right? If not the way I'm doing it, perhaps another way?"

Sorry for the wall of text (I prefer precision over concision) and I welcome any and all remarks.

Community
  • 1
  • 1
doktorpeace
  • 41
  • 4

1 Answers1

0

History manipulation, where websites like Forbes have used it to prevent using the back button to leave the website; has been considered undesirable behavior. It appears that Chrome developers have listed such activity as a bug and deployed a patch against it. (see: https://bugs.chromium.org/p/chromium/issues/detail?id=907167 )

Mentioning this just in case you may have forgot about manually enabling the 'enable-history-manipulation-intervention' flag in Chrome.

Quote (from link): "... the intervention only impacts the back/forward button and not the history.back/forward API"

I see in your 'js-history.js' file; history.pushState, history.state, and history.replaceState; which appear to be working as intended according to the documentation. It's worth noting that their API is considered 'old' according to ( https://developer.chrome.com/docs/web-platform/navigation-api/ ), so although they're not deprecated -- there may be another approach.

GMCaddy
  • 1