Prev: jQuery Attribute Summit--Latest Coverage
Next: Code Guidelines
From: Alan on 21 Dec 2009 14:39
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.
From: David Mark on 21 Dec 2009 16:27
On Dec 21, 2:39 pm, Alan <alan.lar...(a)gmail.com> wrote:
> 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. ;)
From: Alan on 21 Dec 2009 16:53
On Dec 21, 9:27 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> On Dec 21, 2:39 pm, Alan <alan.lar...(a)gmail.com> wrote:
>
>
>
> > 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...
>
>
>
> > 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.  ;)

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.
 | 
Pages: 1
Prev: jQuery Attribute Summit--Latest Coverage
Next: Code Guidelines