[Webkit-unassigned] [Bug 175181] Web Automation: clear element should fire onchange event

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Aug 4 11:28:15 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=175181

Brian Burg <bburg at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #317227|review?                     |review-
              Flags|                            |

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170804/aec27657/attachment.html>


More information about the webkit-unassigned mailing list