break HTMLDocument/DOM of an IFrame if written text contains links




12 years ago
11 years ago


(Reporter: pgbakker, Unassigned)



1.8 Branch
Windows XP
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)



(1 attachment)



12 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070515 Firefox/

If you write the following to a HTMLDocument of an IFrame, you cannot retrieve afterward the body object. Neither does the body show when requesting the innerHTML of the HTML object.

Take out the link and it will all work correctly.


Reproducible: Always

Steps to Reproduce:
1.Place the following into a file and open in a browser:
<script type="text/javascript">
function createNewDoc()

   var mf = document.createElement("IFRAME");
   document.body.appendChild( mf );  
  var txt="<html><head><link rel=\"stylesheet\" type=\"text/css\" href=\"skins/winclassic.css\" /></head><body>Learning about the DOM is FUN!</body></html>";


<input type="button" value="Open and write to a new document" onclick="createNewDoc()">


2. Click the button
3. You will see a popup displaying the result of the innerHTML of the HTML object. As you can see, the body part is missing. Apparently, the bodypart is there, because teh text in teh body is displayed in the IFrame
4. Now remove the link tag from the textstring that is written into the HTMLDocument, refresh and click the button again. You should now see the entire innerHTML of the html object, including the body object.
Actual Results:  
See steps to reproduce

Expected Results:  
It should still be possible to retreive the body object after writing to the HTMLDocument in an IFrame. Also, innerHTML of the html object of the HTMLDocument should display both the header and the body, regardless if there are links in the header

Comment 1

12 years ago
Could you attach the HTML using the "Add an attachment" link?  It makes things easier to deal with.

Comment 2

12 years ago
Created attachment 271976 [details]
testcase as html document 

As requested, the samplecode now as an attachment.



Comment 3

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071105 Minefield/3.0a7pre

Testcase WORKSFORME on trunk. Paul, can you test with a trunk build [0] and confirm? I'd suggest using a new profile to test:

Flags: in-testsuite?
Keywords: testcase
Version: unspecified → 1.8 Branch

Comment 4

12 years ago
Tested it in Minefield: as Adam put it, works fine there.

But the issue is in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070515 Firefox/

I'm not familiar with the update/release scheme's of FF/Mozilla. If the issue is allready fixed for FF3.0, any change of getting that fix backported to the 2.0 branch?


Comment 5

12 years ago
The general policy is that non-critical fixes (i.e. fixes that don't affect security or stability) don't get checked into stable branches.

Comment 6

12 years ago
Resolving as WORKSFORME. We should still get a testcase checked in for this, though.
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME

Comment 7

12 years ago
"We should still get a testcase checked in for this" meaning? Should I do something, or?


11 years ago
Component: DOM: Core → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.