in additional to 354176 - Firefox displays cached iFrame instead of the new iFrame SRC that is defined.

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
--
major
11 years ago
8 days ago

People

(Reporter: jarod, Unassigned)

Tracking

(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

11 years ago
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
(Reporter)

Updated

11 years ago
Severity: normal → critical

Updated

11 years ago
Severity: critical → major

Comment 1

10 years ago
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

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

Comment 3

10 years ago
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

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

Comment 5

8 years ago
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.

Comment 7

8 years ago
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

Comment 9

7 years ago
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

7 years ago
Created attachment 441497 [details]
SlickSpeed IFRAME shows previous IFRAME contents after changing frameworks.

Comment 11

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

Updated

7 years ago
Component: General → General
Product: Firefox → Core
QA Contact: general → general

Comment 12

6 years ago
Created attachment 505892 [details]
Bug Reduction: iframes in HTML

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

Comment 13

6 years ago
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

6 years ago
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

6 years ago
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

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

Comment 17

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

Comment 18

6 years ago
Yes, it still exists in FF 4.

Comment 19

6 years ago
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!

Comment 21

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

Comment 22

6 years ago
Bug still present in Firefox 8.

Comment 23

6 years ago
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

6 years ago
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

5 years ago
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

4 years ago
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

4 years ago
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

4 years ago
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

4 years ago
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

3 years ago
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?

Updated

2 years ago
Blocks: 363840

Updated

2 years ago
Blocks: 402565

Comment 32

2 years ago
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

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

Comment 34

a year ago
This ticket is almost 10 years old.  Switch to Chrome.

Comment 35

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

Comment 36

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

Comment 37

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

Comment 38

a year ago
(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

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

Updated

2 months ago
Duplicate of this bug: 1349006

Updated

2 months ago
Component: General → DOM: Core & HTML

Comment 41

2 months ago
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)

Comment 43

2 months ago
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

2 months ago
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.
You need to log in before you can comment on or make changes to this bug.