608382 - iframes created with document.write() have the content of the wrong iframe reloaded from cache

Status: RESOLVED DUPLICATE of bug 462076

(Core :: DOM: Navigation, defect)

Description

[Alex Orlov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0C)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0C)

When a page has several iframes dynamically created with document.write() calls, and the number of the iframes varies between the different loads of the same page, Firefox inserts the contents of the wrong iframe from the previous page into the newly created iframe on the new page.

Speculation starts here - I think it must be based on the sequence number of the iframe in the page. Let's say, if a given iframe was #2 on the first load, then whatever is the second iframe on the next load, will be loaded with the same content, regardless of the value in the iframe's src attribute.



Reproducible: Always

Steps to Reproduce:
1. clear Firefox cache
2. reload the page at http://dev.adap.tv/alex/testiframeinjection.html several times

Actual Results:  
Note that the javascript on the page is designed to show two Google logos, and insert an Adap.tv logo between them with a probability of 50%
 - if on the first load you see 2 Google logos, then on subsequent loads you sometimes see 3 Google logos
 - if on the first load the Adap.tv logo was inserted, then on subsequent loads you sometimes see a Google logo followed by an Adap.tv logo

Expected Results:  
 - if on the first load you see 2 Google logos, then on subsequent loads you should sometimes see 2 Google logos with an Adap.tv logo between them
 - if on the first load the Adap.tv logo was inserted, then on subsequent loads you should sometimes see 2 Google logos, and no Adap.tv logos.

The reason for the importance of this issue is that it leads to discrepancies in the impressions of banner ads. In the real production scenario, the party inserting the banner (the company I work for) loses the ability to control where and when the banner is displayed. These unintended banner impressions are a significant source of grief for ad networks. Also, the banner showing up in a different place on the page from where it's supposed to leads to bad user experience.

Comment 1

[Alex Orlov]

Also, even though the Google and Adap.tv logos used in the example are not prevented from being cached by the browser, we've also tried serving the iframe source pages with Pragma=no-cache HTTP headed, and the issue still didn't go away.

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirming with a Build built from http://hg.mozilla.org/mozilla-central/rev/fe4898e97431 on WinXP.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm.  Odd that this happens on trunk.  Olli?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

So far I haven't managed to reproduce this on trunk, but I
keep trying...
XtC4UaLL, did you do anything special when when you managed to reproduce this on
trunk.
(On 3.6 this is a well-known bug.)

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

Ermm, ok somehow I got this wrong in half-asleep State ;)

I can confirm the Issue with http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6c8d347bd822 but not with http://hg.mozilla.org/mozilla-central/rev/f322c421f152

(In reply to comment #4)
> (On 3.6 this is a well-known bug.)
Which? Dupe this against that?