Refactoring: Removing an extra boolean 'm_wasModifiedByUser' from

Refactoring: Removing an extra boolean 'm_wasModifiedByUser' from
HTMLInputElement and HTMLTextAreaElement.

'm_wasModifiedByUser' was introduced so that element.validity.tooLong does not return true for values set via JavaScript irrespective of the size of the input value.
Thus this bool was set only for user initiated actions on text controls.

However, the parent class for both: HTMLTextFormControlElement, holds another boolean member 'm_lastChangeWasUserEdit' which too gets set only while performing user initiated editing actions on the form's text controls. [in the defaultEventHandler of textFormControlElement and only if the eventType is webkitEditableContentChanged.]

Thus, instead of maintaining the extra boolean 'm_wasModifiedByUser' in both the HTMLInputElement and the HTMLTextAreaElement classes, we can make use of their parent's 'm_wasModifiedByUser' which holds exactly the same information.

This can be verified by executing layout tests such as:
fast/forms/ValidityState-tooLong-textarea.html
fast/forms/ValidityState-tooLong-input.html
fast/forms/validationMessage.html
which were modified for verifying the validity of the form text controls. (tooLong etc.)

These pass even when using 'm_lastChangeWasUserEdit' instead of 'm_wasModifiedByUser'.

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=162794

[esprehn, 2013-11-26 09:03:20]

This change looks fine to me, but tkent should probably give the final review.

[arpitab_, 2013-11-26 09:23:25]

On 2013/11/26 09:03:20, esprehn wrote:
> This change looks fine to me, but tkent should probably give the final review.

Many thanks for reviewing Elliott! I'll ping tkent for a review.

[tkent, 2013-11-26 09:36:39]

Does this CL work well if the value was set by <datalist> popup or
autocompletion popup?

[arpitab_, 2013-11-26 13:20:39]

On 2013/11/26 09:36:39, tkent wrote:
> Does this CL work well if the value was set by <datalist> popup or
> autocompletion popup?

Hi tkent! 

Sorry for the late reply.
I have verified the behavior for both <datalist> and the autocomplete attribute.

Chrome's behavior in case of <datalist> options is to not show an option that
exceeds the maxLength limit. Thus element.validity.tooLong would always return
false.
However, if I select a <datalist> option and then via JS set the maxLength to a
number less than the length of the input control's current value,
element.validity.tooLong shall return true as expected.

In case of the autocomplete attribute, even though the suggestions do display
options with length greater than the set maxLength for the input control, Chrome
disallows the user to be able to select an option that exceeds the maxLength
value. Thus element.validity.tooLong correctly returns false.
Again, if for this scenario as well, post selecting a suggested option, if the
maxLength of the input control is set to a value less than the length of its
current value, element.validity.tooLong returns true.

[arpitab_, 2013-11-26 13:30:48]

On 2013/11/26 13:20:39, arpitab_ wrote:
> On 2013/11/26 09:36:39, tkent wrote:
> > Does this CL work well if the value was set by <datalist> popup or
> > autocompletion popup?
> 
> Hi tkent! 
> 
> Sorry for the late reply.
> I have verified the behavior for both <datalist> and the autocomplete
attribute.
> 
> Chrome's behavior in case of <datalist> options is to not show an option that
> exceeds the maxLength limit. Thus element.validity.tooLong would always return
> false.
> However, if I select a <datalist> option and then via JS set the maxLength to
a
> number less than the length of the input control's current value,
> element.validity.tooLong shall return true as expected.
> 
> In case of the autocomplete attribute, even though the suggestions do display
> options with length greater than the set maxLength for the input control,
Chrome
> disallows the user to be able to select an option that exceeds the maxLength
> value. Thus element.validity.tooLong correctly returns false.
> Again, if for this scenario as well, post selecting a suggested option, if the
> maxLength of the input control is set to a value less than the length of its
> current value, element.validity.tooLong returns true.

Basically the behavior for <datatlist> and autocomplete does not change with
this change.

[tkent, 2013-11-27 01:16:59]

Another question.  Does this work if:
 1. Load a page with <input>
 2. Fill the input with <datalist>, autocomplete, or autofill.
 3. input.setAttribute("value", "new-value")
  Expected: The value doesn't become "new-value", it should stay the value set
by step 2.

[arpitab_, 2013-11-27 12:20:30]

On 2013/11/27 01:16:59, tkent wrote:
> Another question.  Does this work if:
>  1. Load a page with <input>
>  2. Fill the input with <datalist>, autocomplete, or autofill.
>  3. input.setAttribute("value", "new-value")
>   Expected: The value doesn't become "new-value", it should stay the value set
> by step 2.

Hi tkent,

Have verified the aforementioned scenario for <datalist> as well as
autocomplete.

As you've mentioned, input.setAttribute("value", "new-value") does not change
the input's existing value.
There is no change in the input's value.

[tkent, 2013-11-27 23:39:17]

Thank you for testing.  lgtm.

[commit-bot: I haz the power, 2013-11-27 23:45:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/a.bah@samsung.com/85513002/1

[commit-bot: I haz the power, 2013-11-28 01:58:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/a.bah@samsung.com/85513002/1

[commit-bot: I haz the power, 2013-11-28 02:03:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/a.bah@samsung.com/85513002/1

[commit-bot: I haz the power, 2013-11-28 02:07:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/a.bah@samsung.com/85513002/1

[commit-bot: I haz the power, 2013-11-28 02:18:25]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/a.bah@samsung.com/85513002/1

[commit-bot: I haz the power, 2013-11-28 02:26:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/a.bah@samsung.com/85513002/1

[commit-bot: I haz the power, 2013-11-28 02:35:25]

Change committed as 162794