Closed Bug 215228 Opened 21 years ago Closed 19 years ago

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

Categories

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

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta3

People

(Reporter: Morten, Assigned: bzbarsky)

References

Details

(Keywords: testcase)

Attachments

(3 files)

testcase coming shortly.
Attached file 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.
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
Assignee: rogerl → form
Component: JavaScript Engine → Layout: Form Controls
Keywords: testcase
QA Contact: pschwartau → ian
Version: 1.4 Branch → Trunk
a functioning workaround is to use .value += insteadof .innerHTML +=
Probably a problem with nsGenericHTMLContainerElement::ReplaceContentsWithText,
though nsHTMLTextAreaElement::SetInnerHTML probably also needs to call Reset()
if mValueChanged is false.
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.
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 )
Is bug 208869 related to this one?
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
Depends on: 152329
*** Bug 236131 has been marked as a duplicate of this bug. ***
Attached patch PatchSplinter Review
This "fixes" innerHTML (sorta) and actually fixes setting defaultValue.  For
completely correct rendering, this likely depends on the patch in bug 265367...
Assignee: layout.form-controls → bzbarsky
Status: NEW → ASSIGNED
Attachment #182797 - Flags: superreview?(peterv)
Attachment #182797 - Flags: review?(peterv)
Priority: -- → P2
Target Milestone: --- → mozilla1.9alpha
Summary: innerHTML appends to <textarea> do not work properly → [FIX]innerHTML appends to <textarea> do not work properly
Depends on: 293162
Attachment #182797 - Flags: superreview?(peterv)
Attachment #182797 - Flags: superreview+
Attachment #182797 - Flags: review?(peterv)
Attachment #182797 - Flags: review+
Comment on attachment 182797 [details] [diff] [review]
Patch

Requesting 1.8b3 approval; this is a very safe fix.
Attachment #182797 - Flags: approval1.8b3?
Summary: [FIX]innerHTML appends to <textarea> do not work properly → [FIXr]innerHTML appends to <textarea> do not work properly
Target Milestone: mozilla1.9alpha → mozilla1.8beta3
Comment on attachment 182797 [details] [diff] [review]
Patch

a=chofmann
Attachment #182797 - Flags: approval1.8b3? → approval1.8b3+
Fixed for 1.8b3.  Again, the painting is still a little off until bug 152329
gets fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: