fix: IE 11 and older do not trigger popstate, use hashchange for chec…

[DanielRuf]

IE 11 and older do not trigger the popstate event when the hash changes.
We have to use hashchange in this case.

It is a bug that will not be fixed. See https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/3740423/

Closes #10771

[ncoden]

Same as for others PRs: popstate is used a lot within the framework (Tabs, Accordion, Magellan, Reveal).

Please add an utility in foundation.util.core (or an other utility file if you think it is more appropriate) and avoid code duplication.

[DanielRuf]

Same as for others PRs: popstate is used a lot within the framework (Tabs, Accordion, Magellan, Reveal).

Please add an utility in foundation.util.core (or an other utility file if you think it is more appropriate) and avoid code duplication.

Good suggestion. Similar to the load utility method that you suggested?

[ncoden]

@DanielRuf Exactly (with a better name, specific enough to Foundation)

[ncoden]

@DanielRuf I started implemented a generic popstateEvent method and made some research:

• hashchange is triggered only when the hash change. It is not similar to popstate as it will not be triggered when the url change. IE 8+.
• popstate is triggered when the history state is changed. Edge 14+.

But none of these events will not being triggerd by history.pushState() (see https://codepen.io/ncoden/pen/ddLQmN). Only backward/forward history manipulations will (like clicking on a link or called history.back()). There is a good polyfill here but it works by overriding history.pushState.

The thing is: we do not even need to listen on all history change. We currently use popstate (checked for Accordion, Magellan, Reveal and Tabs) only for window.location.hash, and could rely on hashchange instead without any problems. No need for a polyfill.

[ncoden]

Closing this in favor of #11011