Open Bug 356558 Opened 18 years ago Updated 2 months ago

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

Categories

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

Product:
Core
Component:
DOM: Navigation
Platform:
x86
All
Type:
defect

Tracking

()

People

(Reporter: jarod, Unassigned)

References

Details

Attachments

(4 files)

SlickSpeed IFRAME shows previous IFRAME contents after changing frameworks.
13.46 KB, image/png
Details
Bug Reduction: iframes in HTML
404 bytes, text/php
Details
Bug Reduction: iframe generated by JavaScript
624 bytes, text/html
Details
Regression: iframe src="" changed in setTimeout callback
704 bytes, text/html
Details 
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
Severity: normal → critical
Severity: critical → major
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.

sorry!! replace this "...ist placed at the beginning of the page..." by "...is placed at the end of the page..."!
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?
We are still facing the iframe swapping issue.  Is there anyway to workaround this issue? Please let me know ASAP.
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.
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.
URL: http://remesov.ru/ff-bug
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.
This is most definitely still a problem. I especially see this when testing stuff from a file:// url.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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!
This is indeed still an issue in version 3.6.3. Thank you Dan for the CTRL+F5 work-around.
Product: Firefox → Core
QA Contact: general → general
Added a reduction of this bug of static html generated by PHP.
Added a second reduction where a page generates a randomly-determined iframe url in JavaScript and then inserts that iframe into the DOM.
Adding one final file, a regression/work-around where the generated iframe's src attribute is set in a setTimeout closure.
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=478273 is also related to this.
Has anyone confirmed if this exists in FF 4 or not?
Yes, it still exists in FF 4.
Can also confirm Bug in FF4!
Bug is still present, I ran into it while redesigning my website today. this needs to be looked at!
I confirm this bug with firefox 4 on windows but cannot reproduce it on linux.
Bug still present in Firefox 8.
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!!??
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.
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.)
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!
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.
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 ?
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!
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.
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?
Blocks: 363840
Blocks: 402565
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.
add Cache-Control: "no-cache" to server responses, resource will be then always re-validated in an iframe.
(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.
(In reply to iiiyxep from comment #38)
> X-Frame-Options header is set to ALLOW-FROM my_domain_name.
This header causes the issue.
Component: General → DOM: Core & HTML
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
Flags: needinfo?(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.
Flags: needinfo?(bzbarsky)
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.
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.
(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.
Priority: -- → P2

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.

Severity: major → --
Severity: -- → S3
No longer blocks: 363840
Duplicate of this bug: 363840
No longer blocks: 402565
Duplicate of this bug: 402565
No longer blocks: 1586005
Duplicate of this bug: 1586005
Component: DOM: Core & HTML → DOM: Navigation
Summary: in additional to 354176 - Firefox displays cached iFrame instead of the new iFrame SRC that is defined. → Firefox displays cached iFrame instead of the new iFrame SRC that is defined.

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.

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

Attachment

General

Creator:
Created:
Updated:
Size: