408 bytes, text/html
1.39 KB, text/html
1.78 KB, patch
chris hofmann: approval1.8b3+
|Details | Diff | Splinter Review|
testcase coming shortly.
Created attachment 129265 [details] 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
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.
Created attachment 131956 [details] testcase to see difference to innerhtml, childNodes.nodeValue and value of textarea A bit more elaborate testcase to see the differences between textarea.innerHTML/textarea.childNodes.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.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
14 years ago
Depends on: 152329
*** Bug 236131 has been marked as a duplicate of this bug. ***
Created attachment 182797 [details] [diff] [review] Patch This "fixes" innerHTML (sorta) and actually fixes setting defaultValue. For completely correct rendering, this likely depends on the patch in bug 265367...
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
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
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.