Is this a Firefox remote XMLHttpRequest bug?
A jQuery BBQ user came across a rather interesting behavior in Firefox the other day, so I set up an example page to test things out.. and it turns out I’ve either encountered a completely useless “feature” or a legitimate (and annoying) bug in Firefox when setting location.href
in a remote XMLHttpRequest callback.
So maybe this is a totally ridiculous edge-case, but when I make a cross-domain JSONP jQuery.ajax()
request, if the success callback tries to change the hash by setting location.href = baseurl + "#hash"
instead of location.hash = "#hash"
, things break.. but not in the way you might expect.
And note that if I wrap the location-setting code in a setTimeout
, everything works as-expected.
Now, you might think this is some kind of fancy security feature, “well, some data is coming from an external site, so it’s unsafe to change the location.” Except that the problem isn’t in the location being changed. The location gets changed just fine. The problem is that the previous location loses its history entry, such that hitting the back button actually skips back two locations.
It’s the same behavior you’d expect from a location.replace()
call.
So, I’m going out on a limb here and calling this a bug, which I’ve submitted as Firefox bug 527618. Either way, please check out the example page in Firefox 2-3.6 on any OS for yourself, and let me know what you think!
Also, once I figure out what the deal is, I’ll update jQuery BBQ so that this is no longer an issue.
a
,b
,i
,br
,p
,strong
,em
,pre
,code
.<pre class="brush:js"></pre>
(supported syntax highlighting brushes:
js
,css
,php
,plain
,bash
,ruby
,html
,xml
)<
instead of<
and>
instead of>
in the examples themselves.