Closed Bug 354176 Opened 14 years ago Closed 14 years ago
Firefox displays cached i
Frame instead of the new i Frame SRC that is defined .
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.
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: 14 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.