Dynamic iframe caching problem workaround needed for Firefox

[Alan]

There is a long-standing bug in Firefox whereby iframes, created by
scripting, display incorrectly cached content on reload
https://bugzilla.mozilla.org/show_bug.cgi?id=279048.

In my case, I have a page containing several iframes, and on load they
sometimes get muddled up (content loaded into wrong frame). Manually
refreshing the frames fixes the problem.

Now, as a workaround I have been adding (or removing) a # to the end
of each iframes src attribute after the frame has been created (thus
causing the frame to update with the correct contents). In jQuery this
looks like:

jQuery('iframe').each(function(i) {
if(/#$/.test(this.src))
this.src = this.src.substr(0, this.src.length - 1);
else
this.src = this.src + '#';
});

Up until now this workaround has solved the problem, however today the
client discovered that when they navigate away from the page and then
hit the back button, the work around does not work.

Eventually I found that adding a delay before applying the workaround
solved the problem, suggesting that there is a race condition between
loading of the cached content and refreshing the frame.

jQuery('iframe').each(function(i) {
var date = new Date();
var curDate = null;
do { curDate = new Date(); } while(curDate - date < 2000);

if(/#$/.test(this.src))
this.src = this.src.substr(0, this.src.length - 1);
else
this.src = this.src + '#';
});

However this is obviously not an acceptable solution. Does anyone have
any alternatives? The client thinks that if Google can do we should be
able to too ... Sigh.

 

[David Mark]

There is a long-standing bug in Firefox whereby iframes, created by
scripting, display incorrectly cached content on reloadhttps://bugzilla.mozilla.org/show_bug.cgi?id=279048.

In my case, I have a page containing several iframes, and on load they
sometimes get muddled up (content loaded into wrong frame). Manually
refreshing the frames fixes the problem.

Now, as a workaround I have been adding (or removing) a # to the end
of each iframes src attribute after the frame has been created (thus
causing the frame to update with the correct contents). In jQuery this
looks like:

jQuery('iframe').each(function(i) {
  if(/#$/.test(this.src))
    this.src = this.src.substr(0, this.src.length - 1);
  else
    this.src = this.src + '#';

});

Don't use jQuery (or substr).

var iframes = document.getElementsByTagName('iframe');

for (var i = iframes.length; i-- {
...
}

https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/String/substring

Up until now this workaround has solved the problem, however today the
client discovered that when they navigate away from the page and then
hit the back button, the work around does not work.

Yes, jQuery breaks fast history navigation. Otherwise it would be a
non-issue.

Eventually I found that adding a delay before applying the workaround
solved the problem, suggesting that there is a race condition between
loading of the cached content and refreshing the frame.

jQuery('iframe').each(function(i) {
  var date = new Date();
  var curDate = null;
  do { curDate = new Date(); } while(curDate - date < 2000);

  if(/#$/.test(this.src))
    this.src = this.src.substr(0, this.src.length - 1);
  else
    this.src = this.src + '#';

});

Never do that as it locks up the browser UI.

https://developer.mozilla.org/en/DOM/window.setTimeout

And I can't see why you would need to thrash the locations like that.
What are you using these frames for?

However this is obviously not an acceptable solution. Does anyone have
any alternatives? The client thinks that if Google can do we should be
able to too ... Sigh.

That's a pretty low bar.

 

[Alan]

Don't use jQuery (or substr).

var iframes = document.getElementsByTagName('iframe');

for (var i = iframes.length; i-- {
   ...

}

https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global...




Yes, jQuery breaks fast history navigation.  Otherwise it would be a
non-issue.









Never do that as it locks up the browser UI.

https://developer.mozilla.org/en/DOM/window.setTimeout

And I can't see why you would need to thrash the locations like that.
What are you using these frames for?




That's a pretty low bar.  

Interesting. I hadn't thought about the overhead of using jQuery. Will
give your suggestion a try tomorrow.

As for what we are doing, each frame contains Google widgets or other
content. The frames can then be added and removed and dragged and
dropped to create an iGoogle like dashboard (for a fraction of the
cost, time, and thought!). As I said, this bug in Firefox causes the
iframes to regularly load the wrong content. The location "thrashing"
solves this, seemlessly when it works. I found that setting src = src
or attempts to use reload() weren't working, whereas the # solution
(which I saw in some thread about the bug) did.

Thanks for the ideas.