13.46 KB, image/png
404 bytes, text/php
624 bytes, text/html
704 bytes, text/html
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
We can also confirm this bug in Firefox 184.108.40.206! 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 220.127.116.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.
This is most definitely still a problem. I especially see this when testing stuff from a file:// url.
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.
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Added a reduction of this bug of static html generated by PHP.
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!
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?
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.
This Bug is still present, will anybody do something about this?
This ticket is almost 10 years old. Switch to Chrome.
Same issue here. We desperately need a fix for this one.
What a shame. 10 years is not enough to fix this. Nowadays this is critical a issue for Single Page Application websites.
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.
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
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.
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.
You need to log in before you can comment on or make changes to this bug.