Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent Safari 5.0.x poll from interfering with pushState until hash change propagates #150

Closed
wants to merge 3 commits into from

Conversation

drd
Copy link

@drd drd commented Jan 19, 2012

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?

Eric O'Connell added 3 commits January 19, 2012 14:55
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.
@cmwelsh
Copy link

cmwelsh commented Mar 26, 2012

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?

@drd
Copy link
Author

drd commented Apr 6, 2012

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:

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?


Reply to this email directly or view it on GitHub:
#150 (comment)

@ghost
Copy link

ghost commented Jun 3, 2013

Can anyone re-check this issue with Safari 5?

@drd
Copy link
Author

drd commented Jun 25, 2018

¯_(ツ)_/¯

@drd drd closed this Jun 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants