Bug 57636 – Setting defaultValue on a textarea with a modified value still clobbers the value

• Component: Forms
• Status: RESOLVED FIXED

[Boris Zbarsky]

BUILD: Safari 5, Chrome 12 dev

STEPS TO REPRODUCE: Load attached testcase.

EXPECTED RESULT: Textarea says "PASS"

ACTUAL RESULT: Textarea says "FAIL"

[Boris Zbarsky]

Created attachment 87867 [details]
Testcase

[Alexey Proskuryakov]

Wow.

[Boris Zbarsky]

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.

[Kent Tamura]

IE 9: PASS
Firefox 4: PASS
Opera 11:  FAIL

[Boris Zbarsky]

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.

[Kent Tamura]

Yeah, definitely we should fix this.

[Kent Tamura]

Created attachment 88037 [details]
Patch

[Dimitri Glazkov (Google)]

Comment on attachment 88037 [details]
Patch

ok.

[Darin Adler]

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.

[Kent Tamura]

(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.

[Kent Tamura]

Comment on attachment 88037 [details]
Patch

Clearing flags on attachment: 88037

Committed r82908: <http://trac.webkit.org/changeset/82908>

[Kent Tamura]

All reviewed patches have been landed.  Closing bug.

[WebKit Review Bot]

http://trac.webkit.org/changeset/82908 might have broken GTK Linux 32-bit Release

[Philippe Normand]

(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

[Kent Tamura]

(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.

[Simon Pieters (:zcorpan)]

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.)

[Boris Zbarsky]

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