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

RESOLVED INACTIVE

Status

()

Core
Document Navigation
--
major
RESOLVED INACTIVE
12 years ago
2 days ago

People

(Reporter: iloveluton, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

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

Comment 2

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

Comment 3

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

Comment 4

10 years ago
Created attachment 320170 [details]
Screen-shot of IFRAME before and after from JDGiotta

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.

Comment 5

10 years ago
Created attachment 320775 [details]
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?

Comment 6

10 years ago
Too all that reported this problem, do you have more than one iframe on the page you experience this issue on?

Comment 7

10 years ago
Yes--more than one iframe.

Comment 8

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

Comment 9

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

Comment 10

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

Comment 11

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


Comment 12

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 279048

Comment 14

10 years ago
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
Duplicate of this bug: 315891
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.

Comment 19

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

Comment 21

8 years ago
Created attachment 503539 [details]
www.wesh.com before reloading.

Attaching before image of www.wesh.com.

Comment 22

8 years ago
Created attachment 503540 [details]
www.wesh.com after reloading

Attaching screenshot of www.wesh.com after reloading.  Note the 728x90 iframe from the before image is now in the 300x250 iframe's content.

Updated

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

Comment 23

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

Comment 25

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

Comment 27

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

Comment 28

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

Comment 31

3 years ago
Let's set dependency to bug 356558 (can't hurt)
Depends on: 356558

Comment 32

3 years ago
(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.

Comment 33

2 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.