iOS weirdness.

[mjadobson]

Pushing states in direct response to click events works fine on iOS, the state is added to the stack, and the location-bar changes. However, if the pushState occurs outside of that, the state is still added to the stack, but the location-bar doesn't change.

So this works great:

$("a").click(function (e) {
    e.preventDefault();
    History.pushState(null, null, someurl);
});

But this has quirkiness:

$("a").click(function (e) {
    e.preventDefault();
    window.setTimeout(function () {
        History.pushState(null, null, someurl);
    }, 1000);
});

I looked on stackoverflow to see whether anyone else had encountered this bug, and I think it is the one mentioned here: http://stackoverflow.com/questions/6161701/is-history-api-broken-on-ios-location-bar-doesnt-update-on-pushstate

While this issues doesn't appear in the use-cases shown in the documentation, it does happen to those who trigger History.pushState in the XHR callback, instead of directly on the click event.

[balupton]

Thanks @Sugarstack - yeah that bug suprised me too (as you can see by my comments on that stackoverflow question!) - yeah, can't beat manual testing in some cases ;-)

I will look into fixing this as I have a pretty good idea on a way that would work - create a transparent overlay over the entire screen, when it is pressed then do a replaceState call for the previous state.

Thanks for keeping me on my toes :) Also feel free to fork and fix yourself if you'd like, as I can't provide any time guarantees for the moment unfortunately.

[mjadobson]

I've managed to get a transparent anchor tag covering the page, with a bound "touchstart" event to it. Unfortunately, it only recognises taps, not scrolls or swipes. People don't really tap randomly on the page, so I don't think this solution will work very seamlessly. Did you have something else in mind?

The closest I've gotten to fixing this is to add a hash straight after firing the pushState, but that triggers a second statechange, and its kind of ugly.

[jokeyrhyme]

Any of you guys tried using jQuery's "proxy" function to set the context of the 2nd example's History.pushState() to the same context as in the 1st example? In theory you might be able to avoid jQuery by using the "apply" method found in the prototype for all Functions. I wonder if it's the execution context being different that is the issue?

[yourfavorite]

So I'm not sure if this is the best way to handle this, but I was dealing with this issue and figured out a hack way around it.
History.pushState();
window.location.hash = 'whatevergoeshere';
window.history.back();

So push the state, add a hash, fake the back button to remove the hash. The beauty of this is that now the user can press the back button and will never hit a hash state.

The only issue is that then if the user hits "forward", iOS Safari will start spamming a bunch of errors saying:
"Result of expression 'a' [null] is not an object."

Anyone know how to fix that bit?