write document.documentElement.innerHTML deletes head and body tags

RESOLVED FIXED in mozilla1.9alpha1



HTML: Parser
16 years ago
8 years ago


(Reporter: Marc Schroeder, Unassigned)



Bug Flags:
wanted1.9.1 -
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [fixed by the HTML5 parser])


(2 attachments)



16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126

The following Site shows how the body and head tags are deleted


Reproducible: Always

Steps to Reproduce:
1. Start Site in your Browser 
2. Press Read html
3. press write html
4. press read html
Actual Results:  
The body and head tags are gone

Expected Results:  
Behave like pressing "Read head", "write head", "read head"


16 years ago
Alias: innerhtml
Summary: write document.documentElement.innerHTML deletes head and body tags → write document.documentElement.innerHTML deletes head and body tags
Created attachment 135188 [details]
attachment from given example

I've made a testcase from the example, and I can confirm the bug
Created attachment 135190 [details]
document.documentElement.innerHTML with midas crashing Mozilla example

Probably because of this bug, Mozilla is crashing when midas designMode='on'.
Press designmode on.
Press document.documentElement.innerHTML
Press focus iframe contentWindow
---> crash
The second testcase no longer crashes in current trunk builds.

For the rest, I think the behavior is actually correct, but maybe we could fix
up the fragment sink to HTML-ify the DOM a bit...
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Keywords: testcase

Comment 5

13 years ago
I am still seeing this behavior with:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

I disagree that this behavior is correct. Calling
should not arbitrarily delete the body and head tags, but should really leave
the innerHTML in it's original state surely.
Confirming.  The problem here is as follows (several problems, actually):

1)  The HTML fragment sink ignores OpenHTML calls.
2)  The HTML fragment sink gets a fake OpenBody() from ParseFragment,
    which means it ignores the real OpenBody() call when we parse <body>.
3)  The HTML fragment sink ignores OpenHead() when called with no args, which is
    how it's called in this case.

Reassigning -- the DOM to text conversion here is fine; it's the text to DOM
conversion that's busted.
Assignee: harishd → mrbkap
Component: DOM to Text Conversion → HTML: Parser
Ever confirmed: true
QA Contact: sujay → parser
I tried playing with this a bit ago (when dealing with fallout from the removal
of <endnote>), so I'll take another stab at this soon.


13 years ago
Priority: -- → P3
Target Milestone: --- → mozilla1.9alpha
This bug prevents current version of Web Developer 1.1.3 Extension, from making the full <html> content of a page editable (instead, we can only edit <body> content). For good reason, Web Developer is among the all-time top three or so officially recommended addons (see https://addons.mozilla.org/de/firefox/recommended). Since 2003 (that's 4 years!) Firefox is not able to write custom <html> code back to the DOM without deleting <head> and <body> tags from DOM tree. Which is a pity really...
Perhaps someone with second thoughts on this?


11 years ago
Alias: innerhtml
Not a blocker since this isn't a crasher or regression. Would be great if you could have a look at it though blake?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
This bug was "wanted1.9+", but it didn't make it into 1.9. It is still present in TB3/1.9. Therefore, requesting "wanted 1.9.1". The bug is currently assigned to Blake Kaplan, but he hasn't posted here since 2005. Maybe it should be assigned to someone else, also in view of the fact that we are heading towards the 6th anniversary of this bug...

Flags: wanted1.9.1?
Not critical for 3.1, but please nominate if someone comes up with a patch.
Flags: wanted1.9.1? → wanted1.9.1-


9 years ago
Assignee: mrbkap → nobody
OS: Linux → All
Hardware: x86 → All
The HTML5 parser fixes this.
Depends on: 373864
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
You need to log in before you can comment on or make changes to this bug.