Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>Update</strong></p> <p>This bug was, as far as I can tell, <a href="http://www.bcherry.net/playground/pushstate" rel="nofollow">first reported by Ben Cherry</a>.</p> <p>Here is the corresponding <a href="https://bugs.webkit.org/show_bug.cgi?id=42940" rel="nofollow">bug report</a> and <a href="http://trac.webkit.org/changeset/69432" rel="nofollow">changeset</a> from WebKit.</p> <p>And <a href="http://code.google.com/p/chromium/issues/detail?id=58384" rel="nofollow">the issue from Chromium</a>.</p> <p>I haven't been able to figure out when the bug was fixed in Chrome. If anyone else has, I would greatly appreciate the info.</p> <p>I do know that the bug exists in WebKit 533.21.1 (which is what Safari 5.0.5 uses), and has been fixed by 534.36 (Safari/WebKit nightly) -- but I don't know, and haven't been able to figure out, which intermediary build introduced the fix.</p> <p>There is <a href="http://en.wikipedia.org/wiki/Google_Chrome#Release_history" rel="nofollow">a helpful chart</a> that maps the Chrome version to its WebKit version.</p> <p><strong>Most importantly</strong>, this bug apprently occurs when there is <em>any</em> active network traffic (images loading, Ajax requests, etc.), and not just iframes. If you are trying to implement History API support, or you are using the latest version of <a href="http://www.asual.com/jquery/address/" rel="nofollow">Asual's jQuery Address plugin</a> (which has history support enabled by default), this bug could seriously impact your application.</p> <hr> <p><strong>2nd Update</strong></p> <p>I think I tracked down the exact WebKit version where the fix was introduced (534.10). So, if you are using jQuery and Asual's Address plugin, here's the practical solution:</p> <pre><code>if (!($.browser.webkit === true &amp;&amp; parseFloat($.browser.version) &lt; 534.10)) { // only enable state support if WebKit version &gt;= 534.10 $.address.state("/base/path"); } </code></pre> <p>I hope this helps someone!</p> <hr> <p>I just tested the fiddle in the latest WebKit nightly (r86671), and the state stays in sync, so it must be a bug. Funny how spending a lot of time writing up a question and submitting it immediately inspires the answer.</p> <p>Still, if anyone has a workaround, it would be greatly appreciated.</p> <p>WebKit nightly (r86671):</p> <pre><code>[1305666598481] / [1305666598481] vs [1305666598480] / --------------- [1305666597469] iframe loaded --------------- [1305666597300] popstate: / [1305666597298] $.address change: / [1305666597270] (did popstate or $.address change trigger?) [1305666597269] called history.back() [1305666597269] appended iframe --------------- [1305666596605] popstate: /node [1305666596605] $.address change: /node --------------- [1305666596008] popstate: / [1305666596008] $.address change: / --------------- [1305666595555] $.address change: /node --------------- [1305666595142] $.address change: / --------------- [1305666578600] iframe loaded --------------- [1305666578400] $.address change: /_display/ [1305666578400] $.address init --------------- [1305666577964] popstate: /_display/ </code></pre> <p>Also interesting that Safari now matches the behavior of Chrome and FireFox, firing popstate on page load.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload