Question

In Safari, if there’s an iframe loading, and the user changes the history state by going back or forward, the popstate event isn’t triggered, causing the application state and the window location to be out of sync.

I think that an active XHR request will cause the same behavior, but I haven’t been able to confirm that yet.

Here’s a jsfiddle that will allow you to easily reproduce the issue:
http://jsfiddle.net/neonsilk/muHk8/

You just have to click the links/buttons in order, from 1 to 6.

In Safari 5.0.5, the output is:

(reverse chronological, the important part is the state comparison at the top)

[1305665493096] /
[1305665493096] vs
[1305665493096] /node
---------------
[1305665489955] iframe loaded
---------------
[1305665489806] (did popstate or $.address change trigger?)
[1305665489805] called history.back()
[1305665489805] appended iframe
---------------
[1305665488428] popstate: /node
[1305665488427] $.address change: /node
---------------
[1305665487821] popstate: /
[1305665487821] $.address change: /
---------------
[1305665487179] $.address change: /node
---------------
[1305665486606] $.address change: /
---------------
[1305665485732] iframe loaded
---------------
[1305665485569] $.address change: /neonsilk/muHk8/show/
[1305665485568] $.address init

Yet in Chrome (11) or FireFox (4.0), the output looks like:

(note that the states are in sync)

[1305665609499] /
[1305665609499] vs
[1305665609499] /
---------------
[1305665608360] iframe loaded
---------------
[1305665607770] popstate: /
[1305665607770] $.address change: /
[1305665607758] (did popstate or $.address change trigger?)
[1305665607758] called history.back()
[1305665607758] appended iframe
---------------
[1305665606870] popstate: /node
[1305665606869] $.address change: /node
---------------
[1305665606150] popstate: /
[1305665606149] $.address change: /
---------------
[1305665605551] $.address change: /node
---------------
[1305665604808] $.address change: /
---------------
[1305665603354] iframe loaded
---------------
[1305665602688] $.address change: /neonsilk/muHk8/show/
[1305665602682] $.address init
[1305665602676] popstate: /neonsilk/muHk8/show/

Is this a bug in Safari? And if it is, has anyone discovered a workaround?

(It’s also interesting that both FireFox and Chrome fire a popstate event on page load.)

Answer 1

Update

This bug was, as far as I can tell, first reported by Ben Cherry.

Here is the corresponding bug report and changeset from WebKit.

And the issue from Chromium.

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.

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.

There is a helpful chart that maps the Chrome version to its WebKit version.

Most importantly, this bug apprently occurs when there is any 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 Asual’s jQuery Address plugin (which has history support enabled by default), this bug could seriously impact your application.

---

2nd Update

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:

if (!($.browser.webkit === true && parseFloat($.browser.version) < 534.10)) {
    // only enable state support if WebKit version >= 534.10
    $.address.state("/base/path");
}

I hope this helps someone!

---

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.

Still, if anyone has a workaround, it would be greatly appreciated.

WebKit nightly (r86671):

[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/

Also interesting that Safari now matches the behavior of Chrome and FireFox, firing popstate on page load.