Bug 175181 - Web Automation: clear element should fire onchange event
Summary: Web Automation: clear element should fire onchange event
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebDriver (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-04 01:56 PDT by Carlos Garcia Campos
Modified: 2017-09-01 10:54 PDT (History)
2 users (show)

See Also:


Attachments
Patch (2.70 KB, patch)
2017-08-04 02:00 PDT, Carlos Garcia Campos
bburg: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2017-08-04 01:56:57 PDT
There's a test in selenium to check this that all other browsers pass:

FAIL test/selenium/webdriver/common/correct_event_firing_tests.py::testClearingAnElementShouldCauseTheOnChangeHandlerToFire[WebKitGTK]

========================================================================================== FAILURES ==========================================================================================
____________________________________________________________ testClearingAnElementShouldCauseTheOnChangeHandlerToFire[WebKitGTK] _____________________________________________________________

driver = <selenium.webdriver.webkitgtk.webdriver.WebDriver (session="d04a47a2-3c83-41c8-8acf-848523af1ea5")>, pages = <conftest.Pages object at 0x7fe9772acd10>

    def testClearingAnElementShouldCauseTheOnChangeHandlerToFire(driver, pages):
        pages.load("javascriptPage.html")
        element = driver.find_element_by_id("clearMe")
        element.clear()
        result = driver.find_element_by_id("result")
>       assert result.text == "Cleared"
E       AssertionError: assert ' ' == 'Cleared'
E         -  
E         + Cleared

test/selenium/webdriver/common/correct_event_firing_tests.py:97: AssertionError

The spec doesn't say anything about change event, it says that when clearing a resettable element the element reset algorithm should be run. And the HTML spec says that input events shouldn't be fired when resetting but 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.
Comment 1 Carlos Garcia Campos 2017-08-04 02:00:49 PDT
Created attachment 317227 [details]
Patch
Comment 2 BJ Burg 2017-08-04 11:28:15 PDT
Comment on attachment 317227 [details]
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.