[webkit-reviews] review denied: [Bug 175181] Web Automation: clear element should fire onchange event : [Attachment 317227] Patch

[bugzilla-daemon at webkit.org]

Brian Burg <bburg at apple.com> has denied Carlos Garcia Campos
<cgarcia at igalia.com>'s request for review:
Bug 175181: Web Automation: clear element should fire onchange event
https://bugs.webkit.org/show_bug.cgi?id=175181

Attachment 317227: Patch

https://bugs.webkit.org/attachment.cgi?id=317227&action=review




--- Comment #2 from Brian Burg <bburg at apple.com> ---
Comment on attachment 317227
  --> https://bugs.webkit.org/attachment.cgi?id=317227
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=317227&action=review

r-, let's fix the behavior for simulating the reset algorithm while we are
improving this atom anyway.

> Source/WebKit/ChangeLog:11
> +	   doesn't mention change events. I guess that in these cases it's
better to be consistent with all other
> +	   implementations and what selenium expects.

This is surprisingly difficult to get a straight answer to. The "change" event
has this description:

"Fired at controls when the user commits a value change (see also the input
event)"

and there is more details here
(https://html.spec.whatwg.org/#common-input-element-events):

"For input elements without a defined input activation behavior, but to which
these events apply, any time the user causes the element's value to change
without an explicit commit action, the user agent must queue a task to fire an
event named input at the input element, with the bubbles attribute initialized
to true. The corresponding change event, if any, will be fired when the control
loses focus."

in our case, the user is the webdriver script, and the Clear command seems to
be an abstract user command like undoing typing. There is also the following
example:

"Examples of a user changing the element's value would include the user typing
into a text control, pasting a new value into the control, or undoing an edit
in that control. Some user interactions do not cause changes to the value,
e.g., hitting the "delete" key in an empty text control, or replacing some text
in the control with text from the clipboard that happens to be exactly the same
text."

That makes it sound like "change" event is expected here since the user
committed a value change, as if they had done Ctrl-a, Ctrl-k to kill a line in
a text input. As we implement this with script, a "change" event will never be
fired naturally.

> Source/WebKit/UIProcess/Automation/atoms/FormElementClear.js:49
> +	       if (element.checked) {

Per https://html.spec.whatwg.org/#the-input-element

"The reset algorithm for input elements is to set the dirty value flag and
dirty checkedness flag back to false, set the value of the element to the value
of the value content attribute, if there is one, or the empty string otherwise,
set the checkedness of the element to true if the element has a checked content
attribute and false if it does not, empty the list of selected files, and then
invoke the value sanitization algorithm, if the type attribute's current state
defines one."

In other words, the initial state depends on the "checked" attribute for
checkboxes, and otherwise the "value" attribute should be restored.