BUILD: Safari 5, Chrome 12 dev STEPS TO REPRODUCE: Load attached testcase. EXPECTED RESULT: Textarea says "PASS" ACTUAL RESULT: Textarea says "FAIL"
Created attachment 87867 [details] Testcase
Wow.
Oh, the original context I ran into this in the page was setting .innerHTML, not .defaultValue. But I assume they end up in the same place in the end: modifying the DOM under the textarea. ;) The innerHTML case shows the same problem, of course.
IE 9: PASS Firefox 4: PASS Opera 11: FAIL
Quite interesting. In Opera 11, scripted value changes (as in the attached testcase) on <textarea> allow defaultValue to override value, but if I edit the text in the textarea by typing (as in the original testcase I based mine on) then defaultValue changes don't affect value. I wasn't expecting Opera to have a difference in behavior there. None of the other three rendering engines involved seem to: WebKit shows "FAIL" in both scenarios, while Trident and Gecko show "PASS". Note also that WebKit's behavior here is inconsistent for <textarea> and <input type="text">; the latter behaves as it does in Trident and Gecko.
Yeah, definitely we should fix this.
Created attachment 88037 [details] Patch
Comment on attachment 88037 [details] Patch ok.
Comment on attachment 88037 [details] Patch I think we can eliminate setNonDirtyValue and setValueCommon. Instead, callers can just call setValue and then set m_isDirty to false.
(In reply to comment #9) > (From update of attachment 88037 [details]) > I think we can eliminate setNonDirtyValue and setValueCommon. Instead, callers can just call setValue and then set m_isDirty to false. setValue() needs to call setNeedsValidityCheck(), which must be called after m_isDirty update. So, the current code is efficient.
Comment on attachment 88037 [details] Patch Clearing flags on attachment: 88037 Committed r82908: <http://trac.webkit.org/changeset/82908>
All reviewed patches have been landed. Closing bug.
http://trac.webkit.org/changeset/82908 might have broken GTK Linux 32-bit Release
(In reply to comment #13) > http://trac.webkit.org/changeset/82908 might have broken GTK Linux 32-bit Release fast/forms/ValidityState-tooLong-textarea.html now fails on GTK: --- /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/fast/forms/ValidityState-tooLong-textarea-expected.txt 2011-04-05 01:05:58.793116363 -0700 +++ /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/fast/forms/ValidityState-tooLong-textarea-actual.txt 2011-04-05 01:05:58.793116363 -0700 @@ -31,8 +31,8 @@ PASS textarea.value is "abc" PASS textarea.validity.tooLong is false PASS textarea.validity.tooLong is true -PASS textarea.value is "abcdef" -PASS textarea.validity.tooLong is false +FAIL textarea.value should be abcdef. Was def. +FAIL textarea.validity.tooLong should be false. Was true. PASS successfullyParsed is true TEST COMPLETE
(In reply to comment #14) > (In reply to comment #13) > > http://trac.webkit.org/changeset/82908 might have broken GTK Linux 32-bit Release > > fast/forms/ValidityState-tooLong-textarea.html now fails on GTK: Thank you for reporting. I fixed it by r82913.
Relevant parts of the spec [[ The textarea element represents a multiline plain text edit control for the element's raw value. A textarea element has a dirty value flag, which must be initially set to false, and must be set to true whenever the user interacts with the control in a way that changes the raw value. When the textarea element's textContent IDL attribute changes value, if the element's dirty value flag is false, then the element's raw value must be set to the value of the element's textContent IDL attribute. The defaultValue IDL attribute must act like the element's textContent IDL attribute. ]] http://www.whatwg.org/specs/web-apps/current-work/complete/the-button-element.html#the-textarea-element AFAICT the old behavior matches the spec. (Setting .value doesn't set the dirty value flag.)
I believe that's a bug in the spec, since for <input> setting .value _does_ change the dirty flag in the spec. Filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=12423