Closed Bug 315891 Opened 19 years ago Closed 16 years ago

nested frames/iframes with dynamically changing url do not show correct document

Categories

(Core :: DOM: Navigation, defect)

x86
All
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 363840

People

(Reporter: garbage, Unassigned)

References

Details

(Keywords: qawanted, testcase)

Attachments

(6 files, 1 obsolete file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Maxthon; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050702

Frames and IFrames do not show the Appropriate Site. 
The Sourcecode shows <iframe src=\"sitea.htm\">
When looking at the Information for that IFRame its source is siteb.htm.
This happens if the source alters after reload and the Document is  a nested frame.

That Problem Occurs in following Situation.

The main Document consists  of a frame(I name it CONTENT))(just to keep it simple, the original has more). Additional to that frame is a JavaScript that reloads the Frame periodically. CONTENT itself contains some Content followed by a iframe with a randomly changig source( in this case c.php and c.php) 

The effect you will see is that CONTENT does refresh as expected, but the iframe will always show the doument it initially loaded even though the <iframe src=\"\"> alternates between  b.php and c.php.


Reproducible: Always

Steps to Reproduce:
 1. create Files given in Additional information (copy and paste)and copy them into a folder you can use the PHP files (Apache with PHP installed- sorry I have no Public Domain, project is use in Intranet)
2. open index.php
3. wait for Siteshift visible because \"somkind of Content b/c.php\" changes to \"somkind of Content c/b.php\"
4. expected result ist that the Iframe shows \"I Am\" followed by b/c mathing the site of \"somekind of Content\"
Actual Results:  
Iframe always load the document it loaded first time opened

Expected Results:  
Iframe should load url written in <iframe src=\"\">

This is the Source required for reproducing the Problem.

index.php
--------------------------------------------------------------------------------
<html>
<script>
function refreshContent(){
	window.setTimeout(\"refreshContent()\",10000);
	if(window.Content!=null){
		window.Content.location.reload();
	}
}
refreshContent();
</script>
<frameset rows=\"100\" scrolling = \"no\" noresize border=\"0\">
		<frame src=\"a.php\" name=\"Content\" id=\"Content\" scrolling = \"no\" noresize/>
</frameset>
</html>
--------------------------------------------------------------------------------
a.php
--------------------------------------------------------------------------------
<?php
$urls[]=\"b.php\";
$urls[]=\"c.php\";
$url=$urls[rand(0,1)];


echo\'
<html>
<head>
</head>

somkind of Content
\'.$url.\'
<iframe src=\'.$url.\' style=\"width:100%;height:100%\"></iframe>
</html>
\';
?>
--------------------------------------------------------------------------------
b.php
--------------------------------------------------------------------------------
<?php
echo \"I am b \";
?>
--------------------------------------------------------------------------------
c.php
--------------------------------------------------------------------------------
<?php
echo \"I am C\";
?>
--------------------------------------------------------------------------------


Last but not least! Sorry for my english, I am not speaking english natively.
Attached file The files for reproducing the bug (obsolete) —
OKay those are the PHP files needed to reproduce the bug. Didn't know attachments are possible after the main bug-report-form.
Reporter, your attachment is not usable as it does not appear to be of type text/html.
Can you post an url where we can examine the code, where the bug is happening?

Also note that you are using a rather old (4 months old) Mozilla nightly build. 
"be sure that you've reproduced your bug using a build released within the past three days. Our development process moves at lightning speed, and the bug you've found may already have been fixed."
Bug writing guidelines
http://www.mozilla.org/quality/bug-writing-guidelines.html

You can download the latest nightly build at
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
Keywords: qawanted
Use these files to reproduce failure. Those are PHP files so you need a Webserver with PHP enabled.
Attachment #202526 - Attachment is obsolete: true
(In reply to comment #2)
> Reporter, your attachment is not usable as it does not appear to be of type
> text/html.
> Can you post an url where we can examine the code, where the bug is happening?
> Also note that you are using a rather old (4 months old) Mozilla nightly build. 
> "be sure that you've reproduced your bug using a build released within the past
> three days. Our development process moves at lightning speed, and the bug
> you've found may already have been fixed."
> Bug writing guidelines
> http://www.mozilla.org/quality/bug-writing-guidelines.html
> You can download the latest nightly build at
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

Test with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051110 SeaMonkey/1.5a showed same results.
Confirmed & Testcase

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/2006110904 Minefield/3.0a1

I have tidied up the reporter's example code and hosted the files (because there are multiple).

Testcase:
http://www.oxborrow.net/dev/mozilla/bugs/315891/reload/

Made of four files:
- index.html, frameset. contains javascript to reload the <frame>
- content.php, contains an iframe. the only frame of "index.html". randomly selects a page for the iframe via php
- a.html
- b.html

When tidying this up, I noticed that when I changed reporter's javascript line:
 window.Content.location.reload();
to:
 window.Content.location.href = "content.php";
The expected result occurred.
I have included this working version below to compare:
http://www.oxborrow.net/dev/mozilla/bugs/315891/href/
Reload must take a boolean (true or false) parameter:
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/location.html#1194198

Reporter, is the problem solved if you change

        if(window.Content!=null){
                window.Content.location.reload();

to

        if(window.Content!=null){
                window.Content.location.reload(true);

Please resolve accordingly (as WORKSFORME) if the problem no longer exists.
"By default, the reload method does not force a transaction with the server. However, if the user has set the preference to check every time, the method does a 'conditional GET' request using an If-modified-since HTTP header, to ask the server to return the document only if its last-modified time is newer than the time the client keeps in its cache. In other words, reload reloads from the cache, unless the user has specified to check every time and the document has changed on the server since it was last loaded and saved in the cache."

http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/location.html#1194198

So, best and cross-browser code would be:

if(frames["Content"] != null)
{
frames["Content"].location.reload(true);
};
(tested with:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120405 Minefield/3.0b2pre
)

Dear Gerard,

unfortunately I think the problem is deeper than what was described above.
I have come across this bug due to the problems with ad serving. What actually is happening is, that the content of the iframe is misplaced. Ie. DOM inspector is claiming that the IFRAME node has the src = "contentA", while the real content is contentB etc.

Moreover, a simple experiment with files I have attached (experiment.htm, ifra.htm, ifrb.htm and ifrc.htm) shows, that even with the cache totally disabled the content of IFRAME element is wrong. Although the src atribute is changed to new URL, the request is always made for the original URL. 

So, if the page first was downloaded with iframe's src set to ifra.htm, pressing F5 for reload will always lead for request for ifra.htm even if the src attribute has changed meanwhile to ifrb.htm or ifrc.htm.

This is a content of experiment.htm file (attached). This simulates the real situations happening while ads are served. Please note that it cannot be done any other way because normally, the content of a or b variables is served over the network and one does not know whether they contain IFRAMEs or not.

<html>
<head></head>
<body>
<iframe id='test' src=""></iframe>
	<script>
		frms = ['a','b','c'];
		function rotate() {
			navrat = frms[Math.floor(Math.random()*frms.length)];
			return navrat;
		}

		
		a = "<iframe src='ifr"+rotate()+".htm?bust="+Math.random()+"' width=468 height=60 frameborder=no></iframe>";
		b=  "<iframe src='ifr"+rotate()+".htm?bust="+Math.random()+"' width=468 height=60 frameborder=no></iframe>";
		
				
	</script>
	<script type="text/javascript" language="Javascript">
		document.write(a);
		document.write(b);						
	</script>
</body>
</html>

ifra.htm is red, ifrb.htm is blue and ifrc.htm is green.

One would assume, that this simple script would cause us to see a different combination of colours in iframes with every reload (note the random parameter in the iframe's src URL, cache is disabled and anti-cache headers are returned with every response:
 Expires: Fri, Jan 01 1900 00:00:00 GMT
 Pragma: no-cache
 Cache-Control: no-cache

Unfortunatelly, this is never the case. Reloading the page will always show the initial frame combination and also, the requests to the server are always the same, for example:

GET /mima/ifrc.htm?bust=0.1317169827581437 HTTP/1.1
GET /mima/ifrb.htm?bust=0.40595529484027626 HTTP/1.1

no matter how many times you hit the reload...so even the ?bust parameter does not change, but normal request to the server IS made...

More over, if you modify the experiment slightly, you will see that something is really wrong. Change the experiment.htm this way:

<html>
<head></head>
<body>
	<script>
		a = "<iframe src='ifra.htm?bust="+Math.random()+"' width=468 height=60 frameborder=no></iframe>";
		b =  "<iframe src='ifrb.htm?bust="+Math.random()+"' width=468 height=60 frameborder=no></iframe>";
		
	</script>
	<script type="text/javascript" language="Javascript">
		document.write(a);
		document.write(b);
		
		
		
	</script>
</body>
</html>

so, there are 2 frames, always loading ifra and ifrb respectively. So, the first frame is red, the second is blue if you display the page initially.

After doing so, comment the 
 //document.write(a);
line, so the result will be:

<html>
<head></head>
<body>
	<script>
		a = "<iframe src='ifra.htm?bust="+Math.random()+"' width=468 height=60 frameborder=no></iframe>";
		b =  "<iframe src='ifrb.htm?bust="+Math.random()+"' width=468 height=60 frameborder=no></iframe>";
		
	</script>
	<script type="text/javascript" language="Javascript">
		//document.write(a);
		document.write(b);
		
		
		
	</script>
</body>
</html>

save the file and hit reload.  we have commented out the red iframe, so the expected result would be one blue iframe. 
What is actually displayed is one RED iframe. I.e., the content of the first iframe is placed into the second regardles of its src attribute.

The only time when everything works correctly is when you hit CTRL+F5.

This is really causing severe problems.

If I can provide any further help, I'd be glad to....
Attached file (red frame)
Attached file (blue frame)
Attached file (green frame)
Attached file Testcase
Saving the "Testcase" to a local file and reloading that triggers the bug.
It seems to work when loading directly from Bugzilla though.  Timing issue?
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: General → Embedding: Docshell
Ever confirmed: true
Keywords: testcase
OS: Windows 2000 → All
Product: Mozilla Application Suite → Core
QA Contact: general → docshell
Blocks: 388714
Hi Mats,

yes, it may be a timing issue as with Firebug enabled, the problem does not appear! I forgot to mention that in my previous post.

also, i tried to implement this workaround:

<html>
<head></head>
<body>
	<script>
	
		frms = ['a','b','c'];
		function rotate() {
			navrat = frms[Math.floor(Math.random()*frms.length)];
			return navrat;
		}

		
		a="<iframe name='acko' width=468 height=60 frameborder=no></iframe>";
		b="<iframe name='bcko' width=468 height=60 frameborder=no></iframe>";
	</script>
	<script type="text/javascript" language="Javascript">
		document.write(a);
		document.write(b);
		window.frames['acko'].location = 'ifr'+rotate()+'.htm';
		window.frames['bcko'].location = 'ifr'+rotate()+'.htm';
	</script>
</body>
</html>

this makes the frames reload the content according to newly set location with every reload, but unfortunately, it also fires another request for the location remember from the last "version" of the page...so instead of 2 requests I am getting 3 or even 4...
Isn't this baically a duplicate of the "history restores the document loaded in the frame even if the src changed" bug?
I actually believe that this is related to at least 6 or 7 bugs (either uncofirmed or new) which can be found if you search for iframe in bugzilla.
All are talking about misplaced content in iframes, mostly experienced with ad serving solutions. With the growing popularity of Mozilla (FF), this becomes a real issue for many people...
Just ran into this issue in a production release of our software, frame structure as follows:
Window W_A
- Two tabbed areas (only one is visible)
  - Frame F_A
  - Two tabbed frames (only one is visible)
    - Frame F_B
    - Frame F_C
- Frame F_D

F_C.location.reload() immediately following an async ajax call returning inside F_C loaded the contents of F_D, even though location.href points to the right frame. The problem appears regardless of whether firebug is enabled or not.
Joeri, it sounds like you're seeing a different bug from this one.  Please file it separately, cc me, and attach the HTML files needed to reproduce it.

This bug, based on Mats' testcase, is a duplicate of bug 279048.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE

(In reply to Toby from comment #5)

Confirmed & Testcase

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/2006110904 Minefield/3.0a1

I have tidied up the reporter's example code and hosted the files (because
there are multiple).

Testcase:
http://www.oxborrow.net/dev/mozilla/bugs/315891/reload/

Made of four files:

  • index.html, frameset. contains javascript to reload the <frame>
  • content.php, contains an iframe. the only frame of "index.html". randomly
    selects a page for the iframe via php
  • a.html
  • b.html

When tidying this up, I noticed that when I changed reporter's javascript
line:
window.Content.location.reload();
to:
window.Content.location.href = "content.php";
The expected result occurred.
I have included this working version below to compare:
https://1080ppornlist.com/category/porn-tube-sites/
http://www.oxborrow.net/dev/mozilla/bugs/315891/href/

thumbs up

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

Attachment

General

Creator:
Created:
Updated:
Size: