152329 - Inserting a text node in a textarea displays the text twice

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P2)

Description

[Emmanuel Bourg]

Inserting a text node in a textarea displays the text twice. The text is
incorectly displayed on the first line and doesn't scroll on moving the slider.

Comment 1

[Emmanuel Bourg]

Attachment: Text inserted in a TEXTAREA using the DOM appendChild function

Comment 2

[rods (gone)]

-->

Comment 3

[Terri Preston]

I see this on Win XP branch build 2002061708

Comment 4

[Emmanuel Bourg]

José Jeria provided an interesting screenshot of this bug, see Attachment 109537 [details]

Comment 5

[Kevin McCluskey (gone)]

I can reproduce using (todays) 2003020604 build on WinXP.

Comment 6

[Martijn Wargers (dead)]

Attachment: appenchild method in textarea, alert textarea - innerHTML,childNodes.length etc

I've created a bit more elaborate testcase.

What you can see is, is that if you do textarea.normalize() after you've
appended the textnode, the weird behavior disappears (not all the time, though)


Also, I have made methods to put a paragraph element or a textarea element into
the textarea. You can see how that affects the textarea and different
properties of it.

Comment 7

[Martijn Wargers (dead)]

I think this is somehow related with bug 215228

IMHO:
- Textarea.innerHTML, textarea.childNodes[0].nodeValue, textarea.value and the
text you can see inside the textarea should always be the same.
- Objects generated with the DOM (textnodes, elements, whatever) should be
inserted as strings if they are inserted in the textarea.
- Textarea should never have more than one childNode (a textnode). Any attempts
(textarea.splitText or something like that) should be made undone.

A textarea may contain markup according to the w3c:
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.7
But I don't know if that means, that markup inside a textarea should be
available via the DOM. I don't think it would be usefull for anything.

Comment 8

[Boris Zbarsky [:bzbarsky]]

So the problem here is that we actually construct a frame for the textnode....
Perhaps we should not construct frames on dynamic changes if the parent frame
has the REPLACED_ELEMENT flag set?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

yeah

Comment 10

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

Hmm.. i could have sworn we had an ancient bug for this but i can't find it. I
defenely remember it from when I fixed bug 17003 (amazing, i still remember that
bugnumber).

As I recall it the problem is that we create frames for all but the first
text-child of the textarea. I.e. it seemed like the nsCSSFrameConstructor just
skipped the first childnode of the textarea rather then all of them. That's why
normalize fixes the problem since all textnodes are combined into one.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Perhaps the real problem is that we construct frames for kids of a textarea at
all? Note bug 265367, eg.

Comment 12

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

interestingly, it doesn't seem to happen for xhtml

Comment 13

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

(In reply to comment #7)
> IMHO:
> - Textarea.innerHTML, textarea.childNodes[0].nodeValue, textarea.value and the
> text you can see inside the textarea should always be the same.

No, the spec says otherwise. See bug 17003 comment 81.

> - Objects generated with the DOM (textnodes, elements, whatever) should be
> inserted as strings if they are inserted in the textarea.

Depends on what you mean by 'as strings'. If you insert a node like
<XXX>sometexthere</XXX>
into a textarea we should either insert the text 'sometexthere' or we should
ignore it compleatly, a good argument can be made for either. Right now I think
we ignore it compleatly.

> - Textarea should never have more than one childNode (a textnode). Any attempts
> (textarea.splitText or something like that) should be made undone.

Why? I defenetly don't agree. The DOM should allow for almost any change. How we
render it is something different though. At least that's how I recall the DOM spec.

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

This makes us not construct frames for explicit children of <textarea>.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 185698 [details] [diff] [review]
patch v1

Fix the comment to mention <INPUT TYPE="text"> and TEXTAREA in both places, and
r+sr=bzbarsky

Comment 16

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 185698 [details] [diff] [review]
patch v1

More fixes to make <textarea>.innerHTML work correctly.

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked in.