Closed Bug 293417 Opened 19 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)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
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.
bz, biesi: this is another interesting iframe-related session history bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Perhaps we should study what IE does, and if it makes sense then that should be
what we implement.
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.
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...
In that case I don't really understand the problem in comment 2. That's
presumably what happens now, no?
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+
Flags: blocking-aviary1.1+ → blocking-aviary1.1?
Flags: blocking1.8b3?
I very much doubt there is any chance that session history will be rearchitected
for 1.8.
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
nominating as we've been getting feedback from webapp devs that this is a common issue for them.
Flags: blocking1.9?
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.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-2.0]
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
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"?
Yes, of course.  You can manually remove whatever you want via nsISHistory.
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.
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...  :(
Depends on: 462076
Blocks: backtraps
I'd say this was fixed in bug 462076 and bug 591433.
Please reopen if you disagree.
Status: NEW → RESOLVED
Closed: 14 years ago
Depends on: 591433
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.