Prevent Safari 5.0.x poll from interfering with pushState until hash change propagates #150
Conversation
If a pushState has just occurred and the Safari poller checks to see if the hash has changed before the hashchange propagates, then it sees the new state as being different from the actual state, thus triggering a pushState. This patch sets a flag (waitForPropagation) which is cleared by an interval after the hashchange finally propagates. The question.. what happens if a second pushState occurs before the hashchange propagates?
History.storeState was only updating the urlToId mapping when new states were stored during the session, and then updating the idToState and stateToId mappings on unload, so when the safariStatePoll attempted to check if the current state was the lastSavedState, that function's dependency on extractState would fail as it was using the idToState mapping.
|
I notice that on Safari 5.0.x, sometimes I get constant "statechange" events occurring. This is problematic because in our use case, this manifests as the page constantly reloading. Is that related to this patch? |
|
The problem we had in particular was that the first time we would pushState, the Safari poll would think a statechange had occurred because the document.location.hash had not updated to the new state. This patch introduces a guard which blocks the poll until the hash matches the newly-pushed state. There were some other bugs involved, which included the various stateToId / idToState / urlToState mappings not being properly updated. If you can show me an example I could see if it looks related. On Mar 25, 2012, at 6:55 PM, Chris M. Welsh wrote:
|
|
Can anyone re-check this issue with Safari 5? |
|
¯_(ツ)_/¯ |
If a pushState has just occurred and the Safari poller checks to see
if the hash has changed before the hashchange propagates, then it
sees the new state as being different from the actual state, thus
triggering a pushState. This patch sets a flag (waitForPropagation)
which is cleared by an interval after the hashchange finally
propagates.
The question.. what happens if a second pushState occurs before
the hashchange propagates?