Wrong states when pressing Back button

[roman-sitewits]

To start, the whole library is screwed up, so many issues and so many hours lost. I'd suggest not releasing a crappy library so that hundreds of people don't waste their time.

Now onto the issues.

1. On the Demo page at http://browserstate.github.io/history.js/demo/ if you click states -> 1 -> 2 -> 3 in order and press Back button you should get [state 2] and instead you are getting [state 1](Firefox 48, Chrome 49)
2. On my own clean page, switching states from A to B to C, and while on page C clicking Back button gives me state C, not expected B. Really? Did anyone even test this?
3. And another serious issue that was discussed before: when you say it supports HTML5 History API, it doesn't. With a standard history API when I [pushState] nothing gets triggered, which is awesome, popstate is triggered only when I press browser history buttons. With yours I get popstate triggered while I pushState, just no! I get your approach to handle everything inside the stateChange, but it simply not possible on a collaborative/modular project, I can give you a few real world use cases if you need. One would be when your pager Ajax is handled by CMS, user clicks on a page, the CMS gets new content, you [pushState]. On [popstate] you would trigger pager click to let CMS load that page as a response to history change. Here you can't place everything inside [stateChange] and if your library triggers [popstate] immediately on [pushState] at the click of a pager link it will cause an infinite loop. Add to this that the states are not even popping in the right order and your library is done.

And on behalf of others, thanks for wasting hundreds man-hours. I could have gladly spent this time helping you improve your library, now I'm behind schedule. I'd suggest rename it to [attempted.history.js] so that people don't accidentally assume that it's a solid wrapper for the history API.

[Lysandros-SLR]

Issue 1. I think you missed that it does a replace state and not a push state for state 3 so first we push state 1, then push state 2, then replace state which replaces state 2 with state 3 so naturally our states are now 1 -> 3 not 1 -> 2 -> 3 so going back brings you to state 1.

Issue 2. Not really sure how you get state C when you are already on it. Maybe their are multiple states that are the same.

Issue 3. The fact that it does a statechange when pushing was confusing to me at first and there are quite a few issues talking about this but an easy solution is before you do a push state set a variable to true and on statechange dont do anything if it is set and set it back to false. Be careful about pushing the same state though as pushing the same state wont trigger a statechange, you can get around this by adding some random data to the state there are issues about this as well.

I do agree that this has it quirks and can be tricky to use at times but its not nearly as bad as you make it out to be. Once you figure out how to use it you can do alot with it.