Closed Bug 354176 Opened 18 years ago Closed 18 years ago

Firefox displays cached iFrame instead of the new iFrame SRC that is defined.

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Platform:
All
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 235185

People

(Reporter: jblock, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

It seems there exists a bug in Firefox in the way it caches iFrame content. From what I can tell, when Firefox visits a web page, it creates a cache of all of the content for each of the iFrames for a given page. The problem is that when the user reloads the page (or backs  up into the browser history and requests the page again), Firefox uses the same cached iFrames, even when the iFrames tags have changed.

From what I can tell, this seems to be a problem with static files. We use a javascript banner ad server to rotate iFrame advertisements. As far as Firefox is concerned, the page is a static page. What's interesting is that it does correctly rotate all of our advertisements that are text ads and plain images, but it seems to always reuse the iFrames that it loaded the first time in any subsequent requests.

Reproducible: Always

Steps to Reproduce:
1. Create a basic HTML file with an iframe pointing to cnn. At just before the closing body tag, type "This is cnn.com".
2. Load the file directly in your browser. It will load correctly.
3. Back in your source file, change the SRC value of your iframe to load mozilla.com. Change the message at the end of the file to "This is mozilla."
4. Back in the browser, push reload. You will see that the contents of the iframe are still cnn, but the message at the bottom tells you "This is mozilla.com."
5. To make matters more confusing, if I now add more iFrames to the page, and reload, new iFrames seem to work correctly only on the first page load. If I change the order of the iFrames and reload, it still shows the original order, but the order of my text labels is correct.
Actual Results:  
I saw the first site with the message "This is the first site."

Expected Results:  
I shouuld have seen the second site at the top.

I have found this to be a problem both on the current release of firefox for both mac and pc. It seems like this caching bug may be tied to http response headers for time, because when I attempt to test this with a coldfusion file on a web server, I do not get the problematic behavior. 

However, I run a newspaper website. My articles are ".html" files and we rotate iframes with a banner ad server. This symptom is not a problem in any other browser configuration such as IE or Safari.

I'm going to report this as a "major" for severity because many websites pay for their hosting through iFrame ad tags, like I do with my website. Currently, this Firefox bug is causing my advertisements to not rotate correctly, which will cause a huge problem for my business, as it will with other compaines who depend on advertising tags that need to rotate.
Sorry i just noticed some typos:

Actual Results:  
I saw cnn.com in the iframe but the message said "This is mozilla.com"

Expected Results:  
I shouuld have mozilla.com in the iframe.

Also - when you load the test file into your browser, don't use a web server. Open it directly from within your filesystem. If you put it on a web server, you might not see the problem.
As filed, this is a duplicate of bug 235185.  In e-mail, Jonathan was saying he was running into the following issue:

> Take this situation as an example: 1) User reads a newspaper article. 2) They
> "go back" in the browser history 3) They click on the article link again 4)
> My web application creates a new iframe with a new SRC attribute above the
> others. 5) Firefox incorrectly displays what used to be the first iframe
> inside of the new iframe which appears at the top of the page.

and that's what I told him to file a bug on.

Note that I can't reproduce that problem, so I'd really like to see a testcase actually showing it.  But the steps in comment 0 of this bug are really just bug 235185, as I said.

> The problem is that when the user reloads the page (or backs  up into the
> browser history and requests the page again)

Those are very different situations that follow different codepaths.  Again, if the latter situation shows a problem I'd love to see a testcase.
Though they may be the same base issue, the way it was described to me on the forums is different than bug 235185. Bug 235185 involves altering the src attribute in JavaScript. This involves *the server* sending a different src attribute on reload. To have a testcase, you would need some sort of server scripting, which I assume isn't possible on Bugzilla.

Steps to reproduce:
1. Create a local HTML file: <iframe src="http://mozilla.org">
2. Load that file in the browser.
3. Modify the file to: <iframe src="http://microsoft.com">
4. Reload the file in the browser

Expected: An iframe showing microsoft.com.
Actual: The iframe still shows mozilla.org.

And I'm seeing it on Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060919 Minefield/3.0a1)

The change proposed is that if the iframe's src attribute after the reload is different than before the reload, do not maintain the iframe's state.
Bug 235185 is about reload, period.  It's invalid until someone comes up with a redesign of session history or something.

_THIS_ bug as initially described to me does NOT involve reload.  That's the only case I'm interested in.
(In reply to comment #4)
> Bug 235185 is about reload, period.  It's invalid until someone comes up with a
> redesign of session history or something.
> 
> _THIS_ bug as initially described to me does NOT involve reload.  That's the
> only case I'm interested in.
> 

Boris,

Thank you for taking the time to review this bug information. After a lot of testing, I have found that it seems to be related to RELOAD events only. I'm verry sorry for not having my story straight... I really spent a lot of time tonight to figure out a way to clearly demonstrate the problem.

Here's a link to a video that demonstrates how you can reproduce the problem....

http://www.jonathanblock.com/other/videos/results.html

I tried to post it at the end of Bug 235185, but the system wouldn't let me. Hopefully you can help review the nature of my bug and see it gets directed to the correct place.

Thank you,
Jon 
Jon, thanks a ton for looking into it!

Marking duplicate, I guess.  Good to know that we only have the issues we know we have....

*** This bug has been marked as a duplicate of 235185 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
(In reply to comment #6)
> Jon, thanks a ton for looking into it!
> Marking duplicate, I guess.  Good to know that we only have the issues we know
> we have....
> *** This bug has been marked as a duplicate of 235185 ***

Boris,

One last question - you have marked this as a duplicate of Bug 235185, but that but is marked as resolved. If you were to view the animation I created for you, you will see behavior that clearly looks like an unresolved bug. Can you please inform me as to what the process would be for fixing the issue seen in my demo animation?

Thank you,
Jon
Jon, see comment 4 paragraph one.
(In reply to comment #8)
> Jon, see comment 4 paragraph one.

I'm new to reporting bugs for Firefox, but my understanding is that I have confirmed a known issue, but in paragraph 1 of comment 4 you say that the bug is "Invalid" and to confuse matters, Bug 235185 is marked as "RESOLVED". I guess I am confused by your naming conventions on bug tickets.

Jon
Jon, the "issue" is known.   But the "issue" is that session history, while working as-designed to handle cases users run into daily, causes issues for some sites in some rare circumstances.  The bug resolved invalid requests that we break things for users in general while fixing those rare circumstances.

If someone comes up with a session history design that handles both cases, great.
Component: History → Bookmarks & History
QA Contact: history → bookmarks
I am also having this problem, I've created a new bug describing a very simplistic case to reproduce the issue, since I have no idea how to re-open this bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=478273
This is not fixed ! This bug is 5 years old...
Julien, please file a new bug with a testcase showing your issue.  This bug, as filed, is fixed.
This ticket has not been resolved as invalid, as basically reports the same
issue described above:
https://bugzilla.mozilla.org/show_bug.cgi?id=478273

It is 2 years old and has STILL not been addressed, even in FF 4.
You need to log in before you can comment on or make changes to this bug.