Source: <textarea></textarea></textarea> textarea's innerHTML: </textarea> Source: <div><xmp>&</xmp><div> div's innerHTML: <xmp>&amp;</xmp>
<xmp> probably needs to override GetInnerHTML and call GetContentsAsText like textarea does.
Summary: innerHTML doesn't work in some cases → innerHTML doesn't work right on <xmp>
Just to clarify, it does work correctly in these cases: Source: <div><textarea></textarea></textarea></div> div's innerHTML: <textarea></textarea></textarea> Source: <xmp>&</xmp> xmp's innerHTML: &
Summary: innerHTML doesn't work right on <xmp> → innerHTML doesn't work right in some cases
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).
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.
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.
> 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>.... ;)
Do we not recurse when doing getInnerHTML ?
Nope, we just ask the html-serializer to serialize the children of the node.
or rather, we ask it to serialize the contents of the node. I.e. we only make one call to the serializer.
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.)
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?
<textarea> is special because IE has a bug with it which sites depend on.
Hixie, I tried IE5 and IE6, with this simple HTML; both display <&> <textarea onclick="alert(innerHTML)"><&></textarea>
I was just basing my comments on what bz said earlier in this bug. bz?
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.....
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.
That's a separate issue, and Mozilla's behavior there is correct; please see the existing (invalid) bugs filed on it...
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).
I can find out --> I can not find it.
> 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.
Created attachment 463148 [details] 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 on attachment 463148 [details] Well formed XML, badly parsed in Firefox 4 Look at console.log to see the results of the parsing.
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.
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.
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.