Closed Bug 363840 Opened 18 years ago Closed 2 years ago

IFrame on refresh of page, does not show the correct content.

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 356558
Tracking Flags:
Tracking Status
firefox69 --- affected
firefox70 --- affected
firefox71 --- affected

People

(Reporter: iloveluton, Unassigned)

References

Details

Attachments

(5 files)

Screen-shot of IFRAME before and after from JDGiotta
33.38 KB, image/jpeg
Details
wrong iframe contents.
88.14 KB, image/gif
Details
www.wesh.com before reloading.
415.82 KB, image/png
Details
www.wesh.com after reloading
382.77 KB, image/png
Details
Screenshot after reloading a page which now has a new iframe url
276.04 KB, image/png
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Hello, I have noticed that iframes do not always show the correct contents when refreshing a page. Flow of events: 1. A user opens a page with an iframe that contains a Flash advert from a third party. 2. The user refreshes the same page X number of times (usually 2+) which hits a different third party advert each time via a change of the src attribute of the iframe. 3. When viewing the page via the DOM Inspector extension, we see that the src element of the iframe points to one location (URL), while the contents of the iframe are from a previous page reload. Thanks. M. Reproducible: Sometimes Steps to Reproduce: 1.Create a JSP page that has an iframe that points to either http://www.bbc.co.uk or http://www.yahoo.com. Each time the page is accessed/refreshed, the source element of the iframe will be one of either site mentioned. 2.Access the page and keep refreshing and checking the source value of the iframe element and look at the contents displayed in the iframe. 3.After a short number of refreshes using ctrl-r or f5, you'll find that the physical content of the iframe is different to the source value of the iframe element. Actual Results: The contents of the iframe are different to the src value of the iframe element. Expected Results: The contents of the iframe to be the same as the src value of the iframe element. /*Here is an actual JSP that you can use within Tomcat or Resin etc. to demonstrate this behaviour.*/ <%@page import="java.io.*" %> <%@page import="java.util.Random" %> <% Random generator = new Random(); int randomNumber = generator.nextInt(); int trueOrFalse = randomNumber/2; boolean isPositive = false; if(randomNumber >= 0) { isPositive = true; } %> <html> <head> <title>iframe test - firefox</title> <style> body { font-family: Verdana, tahoma, sans-serif; font-size: 12px; } .title { font-family: Verdana, tahoma, sans-serif; font-size: 14px; } </style> </head> <body> <h2>Firefox iframe test</h2> <p>This page randomly chooses between showing <a href="http://www.bbc.co.uk">http://www.bbc.co.uk</a>, and <a href="http://www.yahoo.com">http://www.yahoo.com</a> in the iframe shown below.</p> <p>Keep hitting <b>F5</b> and check to see if the page you see matches the page stated above the iframe.</p> <p>If the site you see in the iframe is <b>not</b> the same as the site stated, then just check the source of the page to see where the iframe points to.</p> <p>&nbsp;</p> <% if(isPositive) {%> <p class="title">This site should be <b>yahoo.com</b></p> <!-- THIS SITE SHOULD SHOW - http://www.yahoo.com --> <iframe src="http://www.yahoo.com" width="100%" height="50%"></iframe> <%} else {%> <p class="title">This site should be <b>bbc.co.uk</b></p> <!-- THIS SITE SHOULD SHOW - http://www.bbc.co.uk --> <iframe src="http://www.bbc.co.uk" width="100%" height="50%"></iframe> <%}%> <p>&nbsp;</p> <p><b>Note:</b> this may have something to do with the DOM not fully loading. Try hitting <b>F5</b> in quick succession if you find difficulty in recreating the problem.</p> <p>Still not convinced? Try this in Opera, Konqueror, Internet Explorer or Safari.</p> </body> </html>
Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks! If it does, please attach the html in comment 0 to this bug as a testcase ('Add an attachment')
Whiteboard: CLOSEME 07/14
Version: unspecified → 2.0 Branch
Yes, the problem still persists 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) Tested on XP
Hello, I'm also experience the same problem. http://www.turnto10.com/northeast/jar/home.html Like Mr. Matula says, it occurs just after 2 refreshes. OS: Windows XP Sp2 Browser Version: 3.0b5 I'm also attaching a screen-shot
I've circled the iframe area in red. The top portion is the render for the first time and the bottom portion is the render after 2 refreshes.
Attached image wrong iframe contents. —
I am currently reliably able to replicate this issue at http://www.wesh.com/money/index.html after a single refresh. An interesting aspect is that the presence of Firebug 1.0.5 mitigates the issue somewhat (when enabled?)--it makes it much more sporadic/infrequent. Without Firebug installed (or with a beta version), the issue occurs almost every time. Attached is a screen capture with the iframe highlighted via a later version of Firebug and the expected output. The stock graph is only supposed to be displayed once from the URL http://ibs.smartmoney.com/ibs/chart/buildchart.cfm?w=180&ibshatkey=orl . You can see that it is also being loaded where an ad is supposed to land from http://ad.doubleclick.net/adi/ibs.orl.money/national;kw=money+sky1+14458616+C05503_10002+C05503_10104+C05503_10107+C05503_10364+C05503_10394+C05503_10396+C05503_10420;comp=false;ad=true;pgtype=index;tile=6;sz=160x600,120x300;ord=1210693735791?
Too all that reported this problem, do you have more than one iframe on the page you experience this issue on?
Yes--more than one iframe.
(In reply to comment #6) > do you have more than one iframe on the > page you experience this issue on? as it originated as a problem with ads served on page through IFRAMEs and there were many on the page, the answer is yes. You get many contents of IFRAMEs misplaced into other IFRAMEs with this bug.
Then obviously there is a memory problem with IFRAME-to-source relationships. So the question is, what is supposed to tie the two together? I'm interesting in knowing what part of Mozilla/Firefox source is responsible. I maybe naive to the source code, but this seems like a reasonably easy thing to investigate.
(In reply to comment #6) > Too all that reported this problem, do you have more than one iframe on the > page you experience this issue on? > I have only 1 iframe and the bug also occurs; when 2+ quick refreshes, always, and sometimes even after only one refresh (I was trying to create simple PHP script that displays random youtube/google/etc. video from MySQL database in the iframe); in the source code, as mentioned few posts before, location is always good, but the iframe loads the old URL. I used JavaScript setTimeout method to get rid of this on the page (js loads proper iframe content). Windows XP EN SP2, Firefox/3.0.1 (Gecko/2008070208)
WIN XP EN SP2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 The iframe src points to a different server while the content is from the previous call, i have cache disabled and and watching it with TCP monitor and it actually uses the wrong src to re fetch wrong content ~ while externally it shows the right src and wrong content.
Confirmed in Firefox 3.0. Considering this bug is a 2-years old bug from now, are there any workaround for showing multiple iframe in the same page CORRECTLY in Firefox?
Dupe of bug 279048
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Nice! So now we have it "resolved" by making it duplicate of a bug entered in 2005!!!!! This one at least lived... :-( Well we be added automatically in CC of the other bug to watch the "progress"? thanks
This is not a duplicate of bug 279048, since the iframe is not added dynamically. Marking as dependent on that bug (which is fixed), and reopening. Smaug, could we address this by storing for each subframe what URI it had initially and not restoring it from history if the URI is now different from the initial URI or something?
Status: RESOLVED → REOPENED
Component: General → Document Navigation
Depends on: 279048
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → docshell
Hardware: x86 → All
Resolution: DUPLICATE → ---
Whiteboard: CLOSEME 07/14
Version: 2.0 Branch → Trunk
Blocks: 402565
Boris, which testcase did you try? Would be great to have a testcase attached to this bug.
> Boris, which testcase did you try? I didn't; I code-inspected the JSP in comment 0. :( > Would be great to have a testcase attached to this bug. To reproduce this bug as filed you have to have a page that when reloaded hits the server, and you have to have the server return an <iframe> with a different src than the page had for that iframe when it was loaded the first time. So we can't just have a bugzilla attachment that shows the problem. :( Note that we fixed the somewhat similar situation of a document.write that writes out a different URI by treating those frames as dynamically added. The problem in this bug is that the dynamic addition is happening on the _server_, effectively, so is opaque to us. Another possible way to solve this would be to not restore subframes from history if the page being reloaded was a cache miss. That could lead to some odd behavior where what you see on reload depends on whether your cache entry for the toplevel page got evicted or not.... which is suboptimal. Yet another way to "fix" this would be to stop restoring subframes from history altogether, but that degrades the user experience enough that I'm not sure it's worth it to do that. We could also try for some heuristics with <iframe> vs <frame>, but that starts getting ... messy. And unpredictable for authors.
I have experienced this problem as well. I've actually seen iframes content being swapped between multiple iframes on the page. I've seen it in versions of Firefox from 2 to 3.6.13. Clicking on the link from Comment 5, http://www.wesh.com/money/index.html, and hitting refresh a few times, I'm able to repro this pretty consistently. In fact, I'm seeing 728x90 content being rendered in the 300x250 iframe. There is another iframe that is 728x90 that has that exact content before a page reload. Inspecting the DOM and pulling the ad request for the 300x250 slot out into a separate tab, I cannot get the ad server to serve 728x90 content on many reloads, so there's at least circumstantial evidence of iframe content swapping on reload. We have also experienced on back button usage. I will attach screenshots to document this investigation.
Adam, please don't bother testing this sort of thing in anything but the Firefox 4 betas; iframe history loading was heavily revamped in Firefox 4.
Attaching before image of www.wesh.com.
Attaching screenshot of www.wesh.com after reloading. Note the 728x90 iframe from the before image is now in the 300x250 iframe's content.
Attachment #503539 - Attachment description: www.wesh.com before reloading. Note the 728x90 sponsored links block near the bottom of the page. → www.wesh.com before reloading.
This bug is very noticeable with Facebook "Like" button and Google AdSense ads (both use iframes). When FF "Back" and "Forward" buttons are pressed several times, they starts to display itself in each other iframes. Manual refresh heals it sometimes, but sometimes not. Other browsers don't do that. Facebook and Google blames Mozilla for this bug as stated at http://bugs.developers.facebook.net/show_bug.cgi?id=10255 "NEVERMIND. It turns out this is a Mozilla bug, NOT a Facebook bug. Firefox has a problem where sometimes when a page is refreshed, any IFRAME may get its content loaded into another IFRAME on the page. This is why you may have noticed 3rd-party ads showing up in the wrong slots or nothing at all in a slot, the Digg button shows up in an ad's slot, etc. Nobody at Mozilla seems to be interested in fixing this. Google Support has said "Because this bug exists in Mozilla, DCLK cannot fix it. Because Mozilla is an open source application, there is no single corporation or company we can contact regarding their bug." So it doesn't sound like this is going to be fixed any time soon, unless someone who's familiar with Mozilla's internals takes up the challenge of fixing the bug."
Is that happening in Firefox 4? Seriously, read comment 20.
It seems the bug is fixed in FF 4.0b9 I test, but I miss 90% of my addons (I ever don't mention numerous problems, say, blurry fonts which can be worked around only by turning off direct2d knob, etc.) So, could the fix be backported to FF 3.x branch?
Unfortunately, no. It was a major rewrite of session history code, and not really ok for backporting to a security-and-stability-fixes-only branch.
Bug 356558 may be a duplicate of this bug. I just uploaded a number of examples of and a regression to that bug. Disappointing, comment 26, seeing as this is a problem for any site with ads on it.
I'm using Firefox 4.0 here. I have the issue, but the workaround that is : 1) write in html <iframe id="tututu" src="about:blank"></iframe> 2) and then, in javascript, on the load event of the page, change the src : $('tututu').src='http://the.correct.url'; With facebook plugins, you can take the iframe src (not the fbml version), and use this workaround. For Google Adsense, you can use the js version and then write the ads by yourself.
I'm tempted to mark this (and 356558) as dupes of bug 402565 and assume that one covers the remaining issue here. Is that OK?
(In reply to Hallvord R. M. Steen [:hallvors] from comment #29) > I'm tempted to mark this (and 356558) as dupes of bug 402565 and assume that > one covers the remaining issue here. Is that OK? Bug 402565 has a poor summary for the issue and is newer; the other bugs have better comment history for the issue; personally prefer duping them both into bug 356558.
Let's set dependency to bug 356558 (can't hurt)
Depends on: 356558
(In reply to Not doing reviews right now from comment #18) > Another possible way to solve this would be to not restore subframes from > history if the page being reloaded was a cache miss. That could lead to > some odd behavior where what you see on reload depends on whether your cache > entry for the toplevel page got evicted or not.... which is suboptimal. > I think you can save Etag and Last-Modified headers within history entries. When a top-level page is reloaded, compare Etag or Last-Modified in its history entry and those in the server response. If they are not match, reload all subframes, otherwise restore subframes from history. This is independent from cache.

Reloading the page caused the white background iframe to change src from "....?dark=false" to "...?dark=true". Firefox 71 makes a request to "...?dark=false".

Screenshot taken in:
71.0a1 (2019-09-04) (64-bit)

Identical screenshot can be taken in69.0.2

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

status-firefox70: --- → affected

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

Hi Boris

I'm checking old bugs to see if we can resolve some,

Due to Firefox having changes after so many years, maybe this problem doesn't happen anymore. But looking at the bug maybe we can set this bug as a duplicate of bug 356558 ? would that be ok?

thanks

Flags: needinfo?(bzbarsky)

I have to ask: why are you asking me?

Flags: needinfo?(bzbarsky) → needinfo?(pablo.muir)

Oh, I'm sorry, the reason I asked you was because I noticed from the comments that you might have a clue of what is happening with this bug and the other's accounts seem to be disabled. I thought that maybe you might know if its related to bug 356558, mark it as a dupe of that one and keep track of the work on these issues in one place.

Flags: needinfo?(pablo.muir)

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 → --

This sounds basically like bug 356558 so I'll mark the duplicate.

Status: REOPENED → RESOLVED
Closed: 16 years ago → 2 years ago
No longer depends on: 356558
Duplicate of bug: 356558
Resolution: --- → DUPLICATE
No longer blocks: 402565
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: