292881 - docmuent.body.appendChild(document.createElement("iframe")) appends an unusable history entry.

Status: RESOLVED DUPLICATE of bug 237717

(Core :: DOM: Navigation, defect)

Description

[mikol]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Using document.body.appendChild to insert an IFRAME element created with
document.createElement("iframe") adds an unusable history entry each time the
page is [re]loaded. The history entry is unusable because the back button and
keyboard shortcuts do not go back in the history list.

Ironically, the history list is incremented before the appendChild statement,
but only if the appendChild statement is executed. That is, history.length is
the same before and after the appendChild statement, but it is incremented every
time the page is [re]loaded. If the appendChild statement is not reached,
history.length will not be incremented.

Reproducible: Always

Steps to Reproduce:
1. Open appendChildHistoryBug.html in a blank window or tab.
2. Reload the page as many times as you like.

Actual Results:  
After #1 the history list may show a prior entry for appendChildHistoryBug.html,
but it depends on how the page was opened. Dragging the same URL from an
existing tab to a new tab will immediately add an entry, but using the file open
dialog will not add an entry until step #2 is performed.

After #2 the history list will contain one appendChildHistoryBug.html entry for
the initial page load and one additional entry for each subsequent reload.

Expected Results:  
Since the SRC for IFRAME in question has not been specified, and no additional
code is not loading a URL, I would expect the history list to be unaffected.

If a SRC attribute for the IFRAME was specified, I would expect the histroy list
to remain unaffected - just as it remains unaffected when the SRC of an inline
IFRAME is specified.

If a URL is loaded by some other means, I would expect the behavior to be
consistent with the mechanism (e.g., location.replace()) employed.

I am flagging this as Major because it breaks expected history behavior, and I
do not yet have a way to work around the problem.

Comment 1

[mikol]

Attachment: appendChildHistoryBug.html

Comment 2

[mikol]

Comment on attachment 182603 [details]
appendChildHistoryBug.html

A simple HTML page and inline script demonstarting the problem

Comment 3

[Darin Fisher]

bz, biesi: this is apparently a big pain to folks developing rich web apps. 
have you guys seen this bug before?  any thoughts?  IE does not behave this way
apparently.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> have you guys seen this bug before? 

Yep.  Fixed it about 13 months ago.  Just try the testcase in a trunk build.

We really need to get a Gecko-1.8 based Firefox out there.  Badly.


*** This bug has been marked as a duplicate of 237717 ***

Comment 5

[mikol]

Here's a way to work around the problem:

   var myContainer = document.body;
   var myFrame = document.createElement("iframe");
   myFrame.setAttribute("src", "javascript:;");
   
   myContainer.appendChild(myFrame);

Comment 6

[mikol]

I was overly optimistic. The problem is not caused by the append action
directly. Any navigation (including location.replace()) within the inserted
iframe will add unusable entries to history. The solution I proposed in comment
#5 only prevents the initial default navigation to 'about:blank' from happening.