statechange on pushState, make it differ from back/forward button

[pocesar]

Currently, im only using pushState to keep the history, since I'm loading my website content through AJAX. When I call History.pushState, statechange gets called, and call the same content twice. I'm using link event delegation on my website, and I'm having to use a 'hack' and use popstate instead of statechange.
In my code, only when the content changes I use History.pushState(), because I can't do the otherway around. Also, when going back two times using the back button, the getState returns the equivalent to -1 only, and sticks with that forever, which makes it kinda useless.

$(window).bind('popstate', function(e){
  if (typeof e['originalEvent'] !== 'undefined') {
    phery.view('#container').remote(History.getState(false, false).cleanUrl);
  }
});

[jeffwillden]

I think I have the same issue. It sounds like there's no way to pushState() without triggering a statechange, so if you only want statechange to be called for back/forward navigation, you'll have to hack around it by not calling the callback the first time it's pushed onto the stack. Does anyone else know if history.js addresses this use case more elegantly?

[tobyski]

I've run into the same problem when shifting to History.js for IE support, why History.pushState doesn't trigger a identifiably different statechange to browser buttons is odd. Indeed the work around I have in place is the same as jeff which is a pretty nasty, be nice to see a way of handling this in the event handler.

[celevra]

the same problem here...

[edit]
these commits helped me out:
#137
STRML@65130dc

[pocesar]

that was_expected kinda fix it, but still, the back button works just one time, and then sticks to that state forever

[celevra]

no for me it is working perfectly

[pocesar]

currently I decided to drop History.js and, using modernizr, check the browser support for history api natively, IE suckers can have a full page load