Bug 175181 – Web Automation: clear element should fire onchange event

• Component: WebDriver
• Status: NEW

[Carlos Garcia Campos]

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.

[Carlos Garcia Campos]

Created attachment 317227 [details]
Patch

[Blaze Burg]

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.