Last Comment Bug 356558 - in additional to 354176 - Firefox displays cached iFrame instead of the new iFrame SRC that is defined.
: in additional to 354176 - Firefox displays cached iFrame instead of the new i...
Status: NEW
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: x86 All
-- major with 39 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
Blocks: 363840 402565
  Show dependency treegraph
Reported: 2006-10-13 06:01 PDT by jarod
Modified: 2016-05-23 20:32 PDT (History)
37 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

SlickSpeed IFRAME shows previous IFRAME contents after changing frameworks. (13.46 KB, image/png)
2010-04-26 08:22 PDT, Dan POPA
no flags Details
Bug Reduction: iframes in HTML (404 bytes, text/php)
2011-01-21 11:56 PST, Ryan Cannon
no flags Details
Bug Reduction: iframe generated by JavaScript (624 bytes, text/html)
2011-01-21 12:00 PST, Ryan Cannon
no flags Details
Regression: iframe src="" changed in setTimeout callback (704 bytes, text/html)
2011-01-21 12:28 PST, Ryan Cannon
no flags Details

Description User image jarod 2006-10-13 06:01:06 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8.1) Gecko/20061003 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8.1) Gecko/20061003 Firefox/2.0

bug 354176 is unresolved
this is example of this bug.

PS. there is no this bug in Mozilla 1.7.12 

Reproducible: Always

Actual Results:  
but we have reloader.html in iframe

Expected Results:  
After reload of main window we except reloader-confirm.html in iframe
Comment 1 User image Jens J. Parrée 2007-04-16 08:35:33 PDT
We can also confirm this bug in Firefox!

You have a website with three iframes on it. 1st iframe e.g. shows a banner from an adserver! 2nd shows some content from your own website! 3rd shows some google ads.

If the adserver now decides "ok, there have been enough adimpressions for a given banner" and there will be no banner in the 1st iframe after reloading the page, firefox will swap the content of the iframes on the page. E.g. show the old adserver-iframecontent in the 1st-iframe on the reloaded page.

This problem will not appear if the iframe (which might be gone after reload) ist placed at the beginning of the page or all html-code inserted into the page before the actual code of this iframe.

We also did verify, that:

- it is not a http-protocol-header problem sent by the webserver (or proxy)
- a special browser setting (e.g. by some addon or extension)

This Problem can easily be reproduced.
Comment 2 User image Jens J. Parrée 2007-04-16 08:38:04 PDT
sorry!! replace this " placed at the beginning of the page..." by " placed at the end of the page..."!
Comment 3 User image Michal Matula 2007-12-06 04:37:59 PST
Yes, the problem still persist  with, even with the nightly build of 3.x from 12-04-2007.
I have added a test case files and comment to bug # 315891 (which seemed to be related before I found this one)
BTW, there seem to be at least 5 or more bugs like this posted already.
What are the chances to have it fixed any time soon?
Comment 4 User image vinay 2009-02-26 04:37:53 PST
We are still facing the iframe swapping issue.  Is there anyway to workaround this issue? Please let me know ASAP.
Comment 5 User image Jens J. Parrée 2009-02-26 08:01:10 PST
We are still heavily monitoring this bug and still can confirm the precence of the problem in FF 3.0.6 (23.02.2009) under Windows XP Home, XP Pro, Vista Business, OpenSuse 11.1 Gnome, Mac OS X 10.5 (Leopard).

Currently there does not seem do be a stable work arround.
Comment 6 User image Tyler Downer [:Tyler] 2009-03-16 17:36:03 PDT
Can you please add an attachment that shows this issue as a testcase. The given URL gives a 404 now.
Make sure it shows the issue in Firefox 3.0.7 or later safe mode or a new profile.
Comment 7 User image service 2009-05-19 13:38:36 PDT
Why is this still set to unconfirmed after almost 3 years?  It takes less than a minute to test. It's definitely present:

Create a new document with this in the body:

<iframe src=''></iframe>

Load it in Firefox. It will show Google's homepage. Now edit the source so that this is in the body instead:

<iframe src=''></iframe>

Reload the page. It will still show Google. If you view source it will show that the src attribute is set to

Here's a workaround:

<iframe src='' id='ifr'></iframe>

But, that of course won't work when JavaScript is disabled.
Comment 8 User image Heather Arthur [:harth] 2009-11-30 16:19:04 PST
This is most definitely still a problem. I especially see this when testing stuff from a file:// url.
Comment 9 User image Dan POPA 2010-04-26 08:21:10 PDT
Still a problem.

It's quite visible when using SlickSpeed on your local server and play with the frameworks in the config.ini file, adding and removing frameworks (

The IFRAME's load the previous content on page reload even when emptying the browser cache and pressing CTRL+R!

Only CTRL+F5 works!
Comment 10 User image Dan POPA 2010-04-26 08:22:09 PDT
Created attachment 441497 [details]
SlickSpeed IFRAME shows previous IFRAME contents after changing frameworks.
Comment 11 User image Mac 2010-05-26 12:20:22 PDT
This is indeed still an issue in version 3.6.3. Thank you Dan for the CTRL+F5 work-around.
Comment 12 User image Ryan Cannon 2011-01-21 11:56:40 PST
Created attachment 505892 [details]
Bug Reduction: iframes in HTML

Added a reduction of this bug of static html generated by PHP.
Comment 13 User image Ryan Cannon 2011-01-21 12:00:04 PST
Created attachment 505894 [details]
Bug Reduction: iframe generated by JavaScript

Added a second reduction where a page generates a randomly-determined iframe url in JavaScript and then inserts that iframe into the DOM.
Comment 14 User image Ryan Cannon 2011-01-21 12:28:28 PST
Created attachment 505907 [details]
Regression: iframe src="" changed in setTimeout callback

Adding one final file, a regression/work-around where the generated iframe's src attribute is set in a setTimeout closure.
Comment 15 User image Dave 2011-03-05 11:51:43 PST
Please sort this, its actually quite disappointing that a 5 year old bug hasn't even been attempted.

Have been generating the source link from php, have discovered the ONLY way of clearing the cache is to ctrl+F5 it, which of course opens another tab ( a retarded action, why is this even useful )

I had to resort to ie for testing of a page as I was certain it had been me.

If I knew how to fix it i would, frankly its disgusting that ie does something this trivial when firefox can't.
Comment 16 User image Joel 2011-04-05 11:32:43 PDT is also related to this.
Comment 17 User image Brad 2011-04-27 14:03:37 PDT
Has anyone confirmed if this exists in FF 4 or not?
Comment 18 User image Joel 2011-04-27 14:04:23 PDT
Yes, it still exists in FF 4.
Comment 19 User image Jens J. Parrée 2011-04-27 15:44:48 PDT
Can also confirm Bug in FF4!
Comment 20 User image 2011-05-17 20:28:34 PDT
Bug is still present, I ran into it while redesigning my website today. this needs to be looked at!
Comment 21 User image william dode 2011-05-29 02:04:19 PDT
I confirm this bug with firefox 4 on windows but cannot reproduce it on linux.
Comment 22 User image Matthew Grdinic 2011-11-09 11:56:18 PST
Bug still present in Firefox 8.
Comment 23 User image Matthew Grdinic 2011-11-09 12:17:17 PST
I did some more digging and found that:

The iFrame src bug may be triggered by the presence of an id for that iframe.

So for example:

<iframe id="test-1" name="" src=""></iframe>

Load that up and then change it to:

<iframe id="test-1" name="" src=""></iframe>

The iframe still displays

Change the id like so:

<iframe id="test-2" name="" src=""></iframe>

And mozilla still shows.

Remove the id attribute entirely though:

Actually wait no, this doesn't work. Mozilla is still shown.

When we restart the browser, same thing.  

GOOD GOD this is a nightmare bug. It literally persists even after a total browser restart!!??
Comment 24 User image Matthew Grdinic 2011-11-09 12:25:03 PST
Amusingly enough, the src is easily changed in Firebug and works as expected. Reload the page though, same thing, always loads the wrong src.

Again, let me stress: this is even after a full cache clear and full browser restart.
Comment 25 User image henryfhchan 2012-09-23 02:30:32 PDT
this bug is still reproduceable, nightly 18.0a1.

there should be a way for webdevs to opt out of the session restoration behavior.  it causes iframes urls to load in wrong nodes when there is an addition of iframes (esp on blogs, facebook like.)
Comment 26 User image Dean 2013-06-17 00:44:24 PDT
Not sure if this is the same bug, but I'm currently developing a website with iframes.  My iframe HTML loads certain CSS and JS resources, as does the main (top-level) page (a completely different set of files).  As I update files on the server, I can refresh the page, and FF will load the updated versions of my resources for the MAIN page.  But it will continue to load stale CSS/JS files into the iframes, even if I press SHIFT-refresh.

To work around this I either need to completely clear my cache (ensuring my page is not open in any tabs while I do so), or else I can open the relevant JS and CSS files directly in their own tabs and refresh each one, before refreshing my page.

It's getting to be really annoying!
Comment 27 User image Kenneth Lu 2013-06-17 01:59:13 PDT
Dean, read up to comment# 7 for a programmatic workaround. Essentially you can follow up your iframes with some Javascript that tells the frame to reload its own contents, and that javascript reload for some reason makes it open the correct content.
Comment 28 User image Dean 2013-06-19 06:51:08 PDT
Kenneth, thanks, but actually I don't *really* need a workaround - in production, the JS/CSS resources that are not refreshing properly won't change anyhow; they're static files.  My HTML content *does* refresh properly, but that's probable because it's served with headers that forbid caching altogether (generated from PHP script).

BTW, Is this bug a duplicate of #478273 ?
Comment 29 User image Dean 2013-07-02 00:05:34 PDT
It turns out *my* problem has nothing to do with iframes at all.  For some reason my JS/CSS is being served from the BFcache without checking modification date at the server, even when loading the (normally iframed) page in the full window.

Sorry for the irrelevant post!
Comment 30 User image Samuel Reed 2014-10-04 01:30:39 PDT
I have been able to work around this bug by setting a unique `name` attribute on the iframe - for whatever reason, this seems to bust the cache. You can use whatever dynamic data you have as the `name` attribute - or simply the current ms or ns time in whatever templating language you're using.

In my particular case, the iframe is being built via JS, so I simply use ``:

return '<iframe src="' + src + '" name="' + + '" />';

This fixes the bug in my testing; probably because the `` in the inner window changes.
Comment 31 User image Hallvord R. M. Steen [:hallvors] 2014-10-07 05:16:14 PDT
I'm tempted to mark this (and 363840) as dupes of bug 402565 and assume that one covers the remaining issue here. Is that OK?
Comment 32 User image Jozef Parák 2015-10-30 06:42:26 PDT
Dean, what you written in a comment 26. I found the same problem with caching of iframe resources too.
My server was sending only ETag and Last-Modified headers, but nothing like Cache Control or Expiration headers. It seems Firefox 41 applied RFC-2616 13.2.2 Heuristic Expiration. But it applies it ONLY to iframes and does not re-validate iframe JS CSS resources. (resources on Top page was always re-validated)
When I added Cache-Control: "no-cache" header to the responses, then also iframes started to re-validate their resources EVERY TIME.
Comment 33 User image Jens Radtke 2016-01-14 00:43:49 PST
This Bug is still present, will anybody do something about this?
Comment 34 User image Joel 2016-01-14 13:33:21 PST
This ticket is almost 10 years old.  Switch to Chrome.
Comment 35 User image Holger Herbert 2016-01-29 02:30:24 PST
Same issue here.  We desperately need a fix for this one.
Comment 36 User image iiiyxep 2016-04-20 00:15:51 PDT
What a shame. 10 years is not enough to fix this. Nowadays this is critical a issue for Single Page Application websites.
Comment 37 User image Jozef Parák 2016-04-20 01:58:43 PDT
add Cache-Control: "no-cache" to server responses, resource will be then always re-validated in an iframe.
Comment 38 User image iiiyxep 2016-04-20 03:09:08 PDT
(In reply to Jozef Parák from comment #37)
> add Cache-Control: "no-cache" to server responses, resource will be then
> always re-validated in an iframe.

This can't help. In wireshark I can see HTTP-request from Firefox and complete HTTP-response from server with full html contents, but Firefox shows empty iframe and empty response on Network tab of developer tools. 
X-Frame-Options header is set to ALLOW-FROM my_domain_name.
Even if I use the same domain name on main page and for iframe I still see empty content in Firefox.

This issue is both for desktop and mobile Firefox.

P.S. iframe html element is added to document with jQuery. I have front-end nginx server that proxies to its local nodejs back-end server. iframes which returned just by nginx (static html) are fine.
Comment 39 User image iiiyxep 2016-04-20 03:23:50 PDT
(In reply to iiiyxep from comment #38)
> X-Frame-Options header is set to ALLOW-FROM my_domain_name.
This header causes the issue.

Note You need to log in before you can comment on or make changes to this bug.