innerHTML doesn't work right in some cases

NEW
Unassigned

Status

()

Core
DOM
14 years ago
5 years ago

People

(Reporter: neil@parkwaycc.co.uk, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
Source: <textarea>&lt;/textarea&gt;</textarea>
textarea's innerHTML: </textarea>
Source: <div><xmp>&amp;</xmp><div>
div's innerHTML: <xmp>&amp;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>
(Reporter)

Comment 2

14 years ago
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;
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.
(Reporter)

Comment 5

14 years ago
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.
(Reporter)

Comment 13

14 years ago
Hixie, I tried IE5 and IE6, with this simple HTML; both display &lt;&amp;&gt;
<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.....

Comment 16

13 years ago
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...

Comment 18

13 years ago
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

13 years ago
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.
Assignee: general → nobody
QA Contact: ian → general

Comment 21

8 years ago
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 22

8 years ago
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.
Whiteboard: DUPEME
(Assignee)

Updated

5 years ago
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.