234634 - innerHTML doesn't work right in some cases

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P5)

Description

[[e-mail]]

Source: <textarea>&lt;/textarea&gt;</textarea>
textarea's innerHTML: </textarea>
Source: <div><xmp>&amp;</xmp><div>
div's innerHTML: <xmp>&amp;amp;</xmp>

Comment 1

[Boris Zbarsky [:bzbarsky]]

<xmp> probably needs to override GetInnerHTML and call GetContentsAsText like
textarea does.

Comment 2

[[e-mail]]

Just to clarify, it does work correctly in these cases:
Source: <div><textarea>&lt;/textarea&gt;</textarea></div>
div's innerHTML: <textarea>&lt;/textarea&gt;</textarea>
Source: <xmp>&amp;</xmp>
xmp's innerHTML: &amp;

Comment 3

[Boris Zbarsky [:bzbarsky]]

Oh, I see.  So the problem is that the innerHTML needs to be "whatever, when
parsed in the context of this node, will give the current DOM".  So the creation
of innerHTML requires a lot more parser knowledge than we currently use (or want
to use, imo).

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Isn't the bug really in the html-serializer? That it shouldn't escape stuff
inside elements that the parser won't unescape once parsed again?

That way we wouldn't need to have special implementations of .innerHTML in
various elements since that strategy apparently doesn't work.

Comment 5

[[e-mail]]

What I expect is that setting aElement.innerHTML = aElement.innerHTML; should
have no "visible" effect in the DOM, but with the xmp example all the <>&s
become escaped, because the setter works correctly.

A version of the bug affects editor as well, as when you save or switch into
source mode all the <>&s in an <xmp> block become escaped. (4.x used to work
around the problem by converting them all to <pre>s).

I don't understand why textareas were special-cased at all. Support for
unescaped <>&s in textareas is just another backward compatibility quirk.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> I don't understand why textareas were special-cased at all.

Because otherwise, real-world sites broke.  Which is really just not an issue
with <xmp>.... ;)

Comment 7

[Hixie (not reading bugmail)]

Do we not recurse when doing getInnerHTML ?

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Nope, we just ask the html-serializer to serialize the children of the node.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

or rather, we ask it to serialize the contents of the node. I.e. we only make
one call to the serializer.

Comment 10

[Hixie (not reading bugmail)]

Ah. In that case yeah, we should fix the HTML serialiser for XMP. Why does it
work for <xmp> directly though? Does XMP already have a getInnerHTML jobbie?
(the <textarea> case is a special case; <xmp> should be the same whether done
via it directly or its parent.)

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Calling .innerHTML direcly on the xml-element works because the element has an
explicit implementation of GetInnerHTML. See

http://lxr.mozilla.org/mozilla/source/content/html/content/src/nsHTMLSpanElement.cpp#145

What is special about textarea? Why should it behave differently when .innerHTML
is called on its parent?

Comment 12

[Hixie (not reading bugmail)]

<textarea> is special because IE has a bug with it which sites depend on.

Comment 13

[[e-mail]]

Hixie, I tried IE5 and IE6, with this simple HTML; both display <&>
<textarea onclick="alert(innerHTML)"><&></textarea>

Comment 14

[Hixie (not reading bugmail)]

I was just basing my comments on what bz said earlier in this bug. bz?

Comment 15

[Boris Zbarsky [:bzbarsky]]

Hmm.. So the textarea special-casing was done in bug 125746 (needed for
setInnerHTML, sorta, though I guess what we have now screws up entity
references....).  It may not in fact be needed for getInnerHTML on textarea. 
Except then we'll break the invariant that:

foo.innerHTML = foo.innerHTML;

doesn't change anything (it's broken for XMP right now, and it would break for
textarea if we made that change).  Unless we fix those entity reference issues,
of course.

So the point is, we need to have a much smarter serializer.  Editor probably
wants that too, for roundtripping.....

Comment 16

[Jiafu Gao]

I have a similar issue: form.innerHTML does not serialize the value on user
inputs (i.e., the value of <input>, e.g., <input type="text">).

This is a big deal for me since I am dynamically generating highly hierarchical
structs. It is difficult for me to read and save all these values manually. 

Comment 17

[Boris Zbarsky [:bzbarsky]]

That's a separate issue, and Mozilla's behavior there is correct; please see the
existing (invalid) bugs filed on it...

Comment 18

[Jiafu Gao]

Can you show us which bug it is? I can find out.

I am not sure this is the correct behavor. innerHTML is an IE extension to DOM.
If Firefox decides to support it (which it does), should it use IE as reference?
I tested in IE 6.0, it does serialize the form data (user input).

Comment 19

[Jiafu Gao]

I can find out --> I can not find it.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> I tested in IE 6.0, it does serialize the form data (user input).

IE serializes whatever getAttribute returns, as does Mozilla.  The problem is
that for form controls getAttribute in IE is buggy.

Comment 21

[Tim Evans]

Attachment: Well formed XML, badly parsed in Firefox 4

Test case proving innerHTML is working incorrectly in Firefox 4.0b2.
(Version Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b2) Gecko/20100720 Firefox/4.0b2)

Comment 22

[Tim Evans]

Comment on attachment 463148 [details]
Well formed XML, badly parsed in Firefox 4

Look at console.log to see the results of the parsing.

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

Tim,

what is console.log? I get error "console is not defined"

Anyway, your file is html, so innerHTML uses html parsing, not XML parsing.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Olli, Tim's assuming that everyone runs Firebug (bad assumption).  You're correct that his testcase has nothing to do with this bug (which has a summary so broad as to be useless, but is in fact about the innerHTML _getter_).

This bug seems to be a duplicate of the "implement html5 spec for innerHTML" bug.

Comment 25

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.