Closed
Bug 293417
Opened 20 years ago
Closed 14 years ago
If you add an IFRAME and then later remove it after performing some iframe navigations, the history entries aren't removed
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
FIXED
People
(Reporter: jdperlow, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [wanted-2.0])
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
History entries for an IFRAME should be removed if the IFRAME is removed.
Reproducible: Always
Steps to Reproduce:
1. Navigate browser to google.com.
2. Navigate to a page with the following contents:
<html>
<body onload="onload();" >
<script>
var frame;
function onload() {
frame = document.createElement("IFRAME");
frame.onload = onload2;
frame.src="http://www.google.com";
document.body.appendChild(frame);
}
function onload2() {
frame.onload = onload3;
frame.src = "http://www.news.com";
}
function onload3() {
document.body.removeChild(frame);
}
</script>
</body>
</html>
Actual Results:
The history contains multiple entries for the transients states of the IFRAME.
Expected Results:
Since the IFRAME was removed, the history entries should also be removed.
|
||
Comment 1•20 years ago
|
||
bz, biesi: this is another interesting iframe-related session history bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Comment 2•20 years ago
|
||
The problem is that it's not clear what exactly to remove.... I guess we could
remove all global SH entries where the transition was in that iframe. But what
if the iframe is then reinserted? It's still showing the last page we went to
in it... now what?
|
|
||
Comment 3•20 years ago
|
||
Perhaps we should study what IE does, and if it makes sense then that should be
what we implement.
|
||
Comment 4•20 years ago
|
||
We could remove the session history entries once the iframe is garbage
collected, and actually honour them while the iframe exists but is outside the
document. That might be useful in certain scripting scenarios.
|
|
||
Comment 5•20 years ago
|
||
The part of the iframe that interacts with session history (the docshell) is
currently destroyed when the iframe is removed from the document and recreated
when it's put back...
|
|
||
Comment 6•20 years ago
|
||
In that case I don't really understand the problem in comment 2. That's
presumably what happens now, no?
|
|
||
Comment 7•20 years ago
|
||
The session history is stored on the root of the docshell tree.
Any chance of this being fixed for FF1.1? I'm working on a new product that is
encountering this problem in FF but not IE. Would be great to have it in 1.1
Flags: blocking-aviary1.1+
|
|
||
Updated•19 years ago
|
Flags: blocking1.8b3?
|
|
||
Comment 9•19 years ago
|
||
I very much doubt there is any chance that session history will be rearchitected
for 1.8.
|
||
Updated•19 years ago
|
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
|
||
Comment 10•17 years ago
|
||
nominating as we've been getting feedback from webapp devs that this is a common issue for them.
Flags: blocking1.9?
|
|
||
Comment 11•17 years ago
|
||
The time to work on this sort of thing was about 6 months ago or earlier. This is very high-risk code, with great potential for regressions, and completely designed around the assumption of static DOMs (stupid, I know). As module peer, I'd need some serious convincing (and extensive tests) to allow any changes to this code this late in the game.
|
|
||
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9-
|
|
||
Updated•17 years ago
|
Whiteboard: [wanted-2.0]
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
|
||
Comment 14•16 years ago
|
||
As it's tagged "Wanted 2.0", I suppose this bug hasn't / won't be fixed in 1.9.1 ?
In the meantime, has anyone managed to find a workaround ? e.g. in the situation of adding/removing iframes from an extension context.
Basically, is there a way to prune the history using Mozilla API, which would make those iframes "transparent"?
|
|
||
Comment 15•16 years ago
|
||
Yes, of course. You can manually remove whatever you want via nsISHistory.
|
|
||
Comment 16•16 years ago
|
||
Well, using this particular API, I couldn't find what calls to make to remove those iframe-related history entries.
"nsIHistoryEntry.isSubFrame" helped me detect those entries, but I don't know how to explicitly remove them now.
|
|
||
Comment 17•16 years ago
|
||
Hmm. I thought we had an API for removing SHEntries from the SHistory, but we don't seem to. So I take comment 15 back... :(
|
||
Comment 18•14 years ago
|
||
I'd say this was fixed in bug 462076 and bug 591433.
Please reopen if you disagree.
You need to log in
before you can comment on or make changes to this bug.
Description
•