356558 - Firefox displays cached iFrame instead of the new iFrame SRC that is defined.

Status: NEW

(Core :: DOM: Navigation, defect, P2)

Description

[jarod]

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

[Jens J. Parrée]

We can also confirm this bug in Firefox 2.0.0.3!

Example:
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

[Jens J. Parrée]

sorry!! replace this "...ist placed at the beginning of the page..." by "...is placed at the end of the page..."!

Comment 3

[Michal Matula]

Yes, the problem still persist  with 2.0.0.11, 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

[vinay]

We are still facing the iframe swapping issue.  Is there anyway to workaround this issue? Please let me know ASAP.

Comment 5

[Jens J. Parrée]

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

[Tyler Downer [He/Him]]

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

[service]

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='http://google.com'></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='http://yahoo.com'></iframe>

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

Here's a workaround:

<iframe src='http://yahoo.com' id='ifr'></iframe>
<script>document.getElementById('ifr').contentWindow.location.href=document.getElementById('ifr').src</script>

But, that of course won't work when JavaScript is disabled.

Comment 8

[Heather Arthur [:harth]]

This is most definitely still a problem. I especially see this when testing stuff from a file:// url.

Comment 9

[Dan POPA]

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 ( http://mootools.net/slickspeed/).

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

[Dan POPA]

Attachment: SlickSpeed IFRAME shows previous IFRAME contents after changing frameworks.

Comment 11

[Mac]

This is indeed still an issue in version 3.6.3. Thank you Dan for the CTRL+F5 work-around.

Comment 12

[Ryan Cannon]

Attachment: Bug Reduction: iframes in HTML

Added a reduction of this bug of static html generated by PHP.

Comment 13

[Ryan Cannon]

Attachment: 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

[Ryan Cannon]

Attachment: 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

[Dave]

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

[Joel]

https://bugzilla.mozilla.org/show_bug.cgi?id=478273 is also related to this.

Comment 17

[Brad]

Has anyone confirmed if this exists in FF 4 or not?

Comment 18

[Joel]

Yes, it still exists in FF 4.

Comment 19

[Jens J. Parrée]

Can also confirm Bug in FF4!

Comment 20

[ykz]

Bug is still present, I ran into it while redesigning my website today. this needs to be looked at!

Comment 21

[william dode]

I confirm this bug with firefox 4 on windows but cannot reproduce it on linux.

Comment 22

[Matthew Grdinic]

Bug still present in Firefox 8.

Comment 23

[Matthew Grdinic]

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="http://www.mozilla.com"></iframe>

Load that up and then change it to:

<iframe id="test-1" name="" src="http://www.yahoo.com"></iframe>

The iframe still displays mozilla.com.

Change the id like so:

<iframe id="test-2" name="" src="http://www.mozilla.com"></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

[Matthew Grdinic]

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

[henryfhchan]

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

[Dean]

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

[Kenneth Lu]

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

[Dean]

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

[Dean]

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

[Samuel Reed]

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 `Date.now()`:

return '<iframe src="' + src + '" name="' + Date.now() + '" />';

This fixes the bug in my testing; probably because the `window.name` in the inner window changes.

Comment 31

[Hallvord R. M. Steen [:hallvors]]

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

[Jozef Parák]

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

[Jens Radtke]

This Bug is still present, will anybody do something about this?

Comment 34

[Joel]

This ticket is almost 10 years old.  Switch to Chrome.

Comment 35

[Holger Herbert]

Same issue here.  We desperately need a fix for this one.

Comment 36

[iiiyxep]

What a shame. 10 years is not enough to fix this. Nowadays this is critical a issue for Single Page Application websites.

Comment 37

[Jozef Parák]

add Cache-Control: "no-cache" to server responses, resource will be then always re-validated in an iframe.

Comment 38

[iiiyxep]

(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

[iiiyxep]

(In reply to iiiyxep from comment #38)
> X-Frame-Options header is set to ALLOW-FROM my_domain_name.
This header causes the issue.

Comment 41

[Loic]

bz, what's the status of this longstanding bug in Firefox?

There is a workaround posted on stackoverflow's forum: http://stackoverflow.com/a/3984072

Comment 42

[Boris Zbarsky [:bzbarsky]]

There are no concrete plans to change behavior here at the moment, largely because session history is extremely fragile, undertested, and has no web-compatible spec.

Given further that the semantics of "reload" are not actually defined and that in some cases reloading "what the user sees" is in fact the right behavior, it's not even clear-cut that the behavior described is in fact a bug as opposed to a "site author expectations do not match user expectations" situation.

Once there is a spec for session history that we believe is web-compatible and that other browsers are also committed to implementing, we will look into implementing it.  In the meantime, we do not plan to make random behavior changes that may improve some sites but break others and don't exactly align behavior with other browsers.

Comment 43

[dvaughan]

The fact is that when the contents of the iframe are supposed to change they do not. The user is most likely ignorant of the expected change, but therein lies the problem. If the frame is supposed to have changed, which given dynamic content should have, the content should be updated to suit; not locked to the same history due to an "extremely fragile, undertested" program which is steadily becoming the new ie in terms of unreliability and poor design.

There can be all sorts of reasons for having an iframe on a page, and the majority of them may indeed be to hold content which doesn't change or relies on seo compatible path names which would indeed work ( the first time that is, notwithstanding any updates to the content stored in the extremely fragile history ) but this is broken to a point where technically the browser legitimately doesn't support iframes.

The reason its reported here is because its a bug. It'd be nice if it was fixed before I retire, but I can see that there are thousands of other game breaking bugs in the program which are indeed more visible than this, which to the dear user appears to work normally. But DONT go hiding behind an assumption of what the user thinks/expects, its not about what the user thinks or expects, its about what the creators of the web want them to see for that is the whole reason the web experience is created, and at present, your browser is broken and is not fit for purpose.

Comment 44

[henryfhchan]

As far as I can tell, on Internet Explorer and Google Chrome, a refresh causes each highest-level <frameset>/<frame> to reload the user's current url.

Testcase at http://info.ils.indiana.edu/~hrosenba/Demo/DemoFrame1.html. Click on the first link at the bottom right corner.  Then hit F5/CTRL+R.  Expected result is the frame stays on frame 8.

A hard refresh on Internet Explorer (CTRL-clicking the Refresh button or CTRL+F5) leads to frame 2 being loaded back.

This same behavior is consistent with Firefox and Google Chrome.

--

However, for <iframe>s, a F5 / CTRL+R on Internet Explorer and Google Chrome discards all iframe URLs, i.e. they are loaded using the URL specified in the markup.  (Form data is also discarded.)

Firefox differs here by treating <iframe> similar to <frame>.  This differes from other browsers and is unexpected.  <iframe>s are predominately being used for small components like embedded likeboxes, and not for main content, unlike <frame>s. (The last biggest user of full-page iframes, Gmail, is no longer a whole page <iframe> as of 2017.) A much unintended side-effect of this <iframe> URL persisting behavior means if someone introduces a new iframe before other iframes in a webpage (e.g. posting a new blog entry), the <iframe>s will load into the incorrect position (and hence you would be liking something you did not intend -- could possibly be vectorized into a phising attack). I would argue that <iframe> should be treated like <img>, and not persist across refreshes.

Note: I have not tested the cross-browser behavior when calling window.location.reload() from JavaScript.

Comment 45

[burritosaur]

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #42)
> Given further that the semantics of "reload" are not actually defined and
> that in some cases reloading "what the user sees" is in fact the right
> behavior, it's not even clear-cut that the behavior described is in fact a
> bug as opposed to a "site author expectations do not match user
> expectations" situation.

I can also confirm this in a sort of new way. I've created a scrolling activity feed, sometimes these posts contain content embedded in iframes, like YouTube videos. It's sorted from newest to oldest. No dynamic client side activity with javascript.

If I have these 3 iframe scattered down the page:

<iframe src="C"></iframe> - video C displays
<iframe src="B"></iframe> - video B displays
<iframe src="A"></iframe> - video A displays

Everything matches and all is right. If a new video gets added to the top of the feed, I end up with this

<iframe src="D"></iframe> - video C displays
<iframe src="C"></iframe> - video B displays
<iframe src="B"></iframe> - video A displays
<iframe src="A"></iframe> - video A displays

So it *seems* to be caching the iframes purely based on their relative position in the document, which definitely does not match anyone's expectations, user or not. If an iframe's src changes (ideally, any of its markup), it should not get dragged out of the cache. It's no longer the same iframe then.

Comment 47

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 51

[leite.carvalho]

i don't know why this is so controversial:

the specs cleary state:

"The src attribute gives the URL of a page that the element's content navigable is to contain. The attribute, if present, must be a valid non-empty URL potentially surrounded by spaces "

if you navigate inside the iframe and then refresh, the url must be the url being embedded.
if its not, it fails this spec because the navigated content is not the resource being initially embedded.