Fun fact: Chrome does not synchronously fire popstate for fragment navigations. It waits until "document close", i.e. load event fire time. You can see this by opening your console on https://boom-bath.glitch.me/popstate-location-href.html and observing different results in Firefox vs. Chrome.

Combined with the fact that we queue hashchange events (per the original post in this issue), this bit us recently in https://bugs.chromium.org/p/chromium/issues/detail?id=1254926. The basic situation is

<!doctype html>
<script>
window.onload = () => console.log("load");
window.onpopstate = () => console.log("popstate");
window.onhashchange = () => console.log("hashchange");
location.hash = "#1";
</script>

Chrome is trying to introduce a HTML parser that yields to the event loop more often before the load event, and doing so causes the ordering of these events to flip:

Without yielding (current Chrome), we queue hashchange, fire to the load event, fire popstate, then yield and the queued hashchange fires. So: load, popstate, hashchange.
With yielding, we queue hashchange, yield, fire hashchange, fire the load event, fire popstate. So: hashchange, load, popstate.

I'm not sure what the right solution is here, but I don't like how this sort of stuff makes the yield points observable. I suspect the blame lies with queuing hashchange since that makes it run at the next yield point. Maybe we can hold both hashchange and popstate until the load event, and either queue or synchronously fire hashchange then.

popstate/hashchange dispatching doesn't match what browsers do. #1792

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions