Looking at both popstate and hashchange event interfaces for inspiration, I was thinking that it may be useful to have the statechange event interface look something like the following:

interface StateChangeEvent : Event {
  readonly attribute USVString oldURL;
  readonly attribute USVString newURL;
  readonly attribute any state;
};

dictionary StateChangeEventInit : EventInit {
  USVString oldURL = "";
  USVString newURL = "";
  any state = null;
};

I'm not entirely sure the oldURL would be necessary, but I think making it more in-line with how the hashchange event interface is would potentially be nice.

I'm not entirely sure the oldURL would be necessary, but I think making it more in-line with how the hashchange event interface is would potentially be nice.

actually, now that I've looked at it, I think it would be great to have the oldURL as well. This would enable people to listen to a single event and only respond to events that they care about - e.g. path changes, and/or hash changes, and/or search changes.

There appears to be lots of people that want to ignore hash changes in the popstate event:

For example: user is on /path, clicks on a link <a href="#sub">link</a>, and then clicks the browser back button to go back to /path. This fires a popstate event but there could be a usecase where the dev doesn't care about hash changes and can bail early - for example, in React, you could bail out of rerendering here.

A couple questions I'm thinking through with this:

1. Should statechange be fired when you call history.replaceState(history.state, document.title, location.pathname), where the state, title, and path are not changing?
2. Should statechange be fired when the state changes, but not the document title or Location?

One additional thing that would be useful to know is whether the navigation is a pop (going back a page in history), a replace (overwriting the current page in history), or a push (adding a new page to history).

It's currently impossible to accurately detect this sort of thing using history.length. There was some previous work around exposing a history.index value, but that didn't go anywhere and would still be less useful than an event.

A couple questions I'm thinking through with this:

1. Should statechange be fired when you call history.replaceState(history.state, document.title, location.pathname), where the state, title, and path are not changing?
2. Should statechange be fired when the state changes, but not the document title or Location?

My naive first impression is yes - it should fire when popstate fires. And then with oldURL / newURL you can just bail early if you don't need to do anything?

One additional thing that would be useful to know is whether the navigation is a pop (going back a page in history), a replace (overwriting the current page in history), or a push (adding a new page to history).

It's currently impossible to accurately detect this sort of thing using history.length. There was some previous work around exposing a history.index value, but that didn't go anywhere and would still be less useful than an event.

Interesting. But it may be a barrier to getting this proposal being adopted if we do co-opt it. Perhaps if an additional proposal could work out the issues with the previously blocked proposal, then we could add additional info to the event at that time or something?

Small update: I changed the proposed event name to potentially be historychange instead of statechange

I don't have all the context for why popstate is named as it is, but statechange was modeled after it. However, if all things are equal, I think historychange makes more sense as an event name.

One additional thing that would be useful to know is whether the navigation is a pop (going back a page in history), a replace (overwriting the current page in history), or a push (adding a new page to history).

I agree - this would be a nice additional property to add to the statechange event. I don't think we'd run into the same problems as the history.index proposal since indicating replace / push / pop is not difficult to achieve in this edge case that seemed to kill the history.index proposal.

One additional thing that would be useful to know is whether the navigation is a pop (going back a page in history), a replace (overwriting the current page in history), or a push (adding a new page to history).

I agree - this would be a nice additional property to add to the statechange event. I don't think we'd run into the same problems as the history.index proposal since indicating replace / push / pop is not difficult to achieve in this edge case that seemed to kill the history.index proposal.

I'm still somewhat hesitant about this - I think it should be resolved in its own proposal, and then once accepted we can simply add that detail to the event we fire. It seems like a good way of ensuring this proposal doesn't get blocked on issues that may come up with adding that information.

(An addition thought on that as well: what would that detail be if you do location.hash = 'newhash'? The history stack had a new push to it, but also it was a replacement of the existing hash, so would it be a replace event or a push event?)

I'm still somewhat hesitant about this - I think it should be resolved in its own proposal, and then once accepted we can simply add that detail to the event we fire. It seems like a good way of ensuring this proposal doesn't get blocked on issues that may come up with adding that information.

If it causes complications, we could remove it? I am not seeing how it would add complications.

(An addition thought on that as well: what would that detail be if you do location.hash = 'newhash'? The history stack had a new push to it, but also it was a replacement of the existing hash, so would it be a replace event or a push event?)

My understanding is that this is a push, since it adds an entry to the stack. You can tell because pressing the back button takes you back to the URL from before the hash change.

Hey folks! I've been aware of the issues with history for a while, but toward the end of last year fixing them became one of my major projects at work. The conclusion I and others at Google came to over the last month or so is that the the problem goes deeper than just the popstate event being bad: the entire window.history API is subpar.

Our initial proposal for fixing this is at https://github.com/slightlyoff/history_api/blob/master/app_history.md, and I'd love thoughts from you all. In particular, re-reading this thread I see some great feedback on what information would be useful to include in such events, which I'm not sure we've currently captured. In general, I'd appreciate web developers supplying use cases and small code examples I could incorporate into the explainer.

Specifically, the app history API proposal's currententrychange event seems to cover the use cases from your original post. But other parts of the proposal, e.g. the navigate event, might be more suitable for some of the router-like use cases.

Let me know what you think. In particular, if you're interested in exploring this further, please lend your support as a comment (not just thumbs-up!) in WICG/proposals#20 so that the WICG chairs can grant us a repository for incubation.