215228 - [FIXr]innerHTML appends to <textarea> do not work properly

Status: RESOLVED FIXED

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

Description

[Morten Nilsen]

testcase coming shortly.

Comment 1

[Morten Nilsen]

Attachment: testcase

Clicking the button three times seem to work, the fourth click had no result on
my pc, but editing in the textarea, mozilla only "sees" the first one
using ctrl-r, the textarea is cleared, and then clicking the button resumes
counting at the last value.
typing in the textarea, then clicking the button yields weird results as well.
doing this in a form and submitting the results also don't give the expected
results.

Comment 2

[Andrew Schultz]

confirmed with linux trunk 20030805

debug build asserts on forth and later clicks:
###!!! ASSERTION: bad status: 'NS_FRAME_IS_COMPLETE(aStatus)', file
nsBoxToBlockAdaptor.cpp, line 888

==> form controls

Comment 3

[Morten Nilsen]

a functioning workaround is to use .value += insteadof .innerHTML +=

Comment 4

[Boris Zbarsky [:bzbarsky]]

Probably a problem with nsGenericHTMLContainerElement::ReplaceContentsWithText,
though nsHTMLTextAreaElement::SetInnerHTML probably also needs to call Reset()
if mValueChanged is false.

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase to see difference to innerhtml, childNodes[0].nodeValue and value of textarea

A bit more elaborate testcase to see the differences between
textarea.innerHTML/textarea.childNodes[0].nodeValue and textarea.value.

Also a difference if the textarea already has content or not.

Comment 6

[Martijn Wargers (dead)]

I think this bug is related with bug 152329

I think that if changes are made to
textarea.innerHTML/textarea.childNodes[0].nodeValue should also be reflected in
textarea.value and vice versa.

If tags are added with innerHTML inside a textarea (e.g. <p>test</p>) etc. they
should be added as strings and not as new nodes. (but that is probably more in
the realm of bug 152329 )

Comment 7

[José Jeria]

Is bug 208869 related to this one?

Comment 8

[Morten Nilsen]

It could be the same underlying problem, but this particular bug has a very
different appearance (compare the testcases)

Not marking any duplicates for the time beeing

Comment 9

[:Gavin Sharp [email: [e-mail]]]

*** Bug 236131 has been marked as a duplicate of this bug. ***

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

This "fixes" innerHTML (sorta) and actually fixes setting defaultValue.  For
completely correct rendering, this likely depends on the patch in bug 265367...

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 182797 [details] [diff] [review]
Patch

Requesting 1.8b3 approval; this is a very safe fix.

Comment 12

[chris hofmann]

Comment on attachment 182797 [details] [diff] [review]
Patch

a=chofmann

Comment 13

[Boris Zbarsky [:bzbarsky]]

Fixed for 1.8b3.  Again, the painting is still a little off until bug 152329
gets fixed.