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

drd · 2012-01-19T23:18:01Z

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?

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 · 2012-03-26T01:55:16Z

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 · 2012-04-06T23:15:02Z

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 · 2013-06-03T14:42:55Z

Can anyone re-check this issue with Safari 5?

drd · 2018-06-25T17:48:00Z

¯_(ツ)_/¯

Eric O'Connell added 3 commits January 19, 2012 14:55

add guard for pushState occurring while already waiting for propagation

0145f47

drd closed this Jun 25, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

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

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

Uh oh!

drd commented Jan 19, 2012

Uh oh!

cmwelsh commented Mar 26, 2012

Uh oh!

drd commented Apr 6, 2012

Uh oh!

ghost commented Jun 3, 2013

Uh oh!

drd commented Jun 25, 2018

Uh oh!

Uh oh!

Uh oh!

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

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

Uh oh!

Conversation

drd commented Jan 19, 2012

Uh oh!

cmwelsh commented Mar 26, 2012

Uh oh!

drd commented Apr 6, 2012

Uh oh!

ghost commented Jun 3, 2013

Uh oh!

drd commented Jun 25, 2018

Uh oh!

Uh oh!