disable "unfocusing steps" after clear() in SelenideElement#setValue()

GIVEN An application with an input field with the submit handler bound to “blur event” (example: edit field $(".editing .edit") of a task in any app from todomvc.com). WHEN $(".editing .edit").setValue("new task name") THEN: the input field will be:

• old selenium behaviour (at least till ~ 3.6.0) => the input field will be submitted with "new task name" value
• new selenium webdriver behavior => the input field will be submitted with "" value and then fail with being unable to set the value to “new task name”.

The reason for that is that previously selenium did not do any “events firing” after clear():

    /*
     * ...
     * Note that the events fired by this event may not be as you'd expect.  In particular, we don't
     * fire any keyboard or mouse events.  If you want to ensure keyboard events are fired, consider
     * using something like {@link #sendKeys(CharSequence...)} with the backspace key.  To ensure
     * you get a change event, consider following with a call to {@link #sendKeys(CharSequence...)}
     * with the tab key.
     */
    void clear();

but now it does according to the w3c standard: It runs “unfocusing events”…

Somebody does not like this behavior in selenium and considers it as a bug

Somebody really wants this and wants even more events to be fired after clear.

I believe that from the “real user” perspective the new behavior of the clear method in selenium - is ok and really natural. If we consider “clear()” as “atomic user operation” on element - then this is natural to fire corresponding events after it.

But then… if we continue to consider operations from the user perspective, i.e. as if they are “atomic user operations”, then now SelenideElement#setValue is no atomic any more, since it is based on clear() being called before sendKeys()… Continuing this logic, I believe that we should find a way to disable “firing events” after clear() and before sendKeys inside setValue implementation. No need to fire events twice, we need to do that just once at the end of “atomic user operation”, i.e. at the end of setValue()…

Potential implementation could be to change “clearing” implementation to be based on js instead of WebElement#clear(). We also can put it under Configuration.clearByJsInsideSetValue or Configuration.fireUnfocusingEventsAfterClearInSetValue or Configuration.someBetterName 😃

P.S. by the way Configuration.fastSetValue can be used as workaround so far… Yet I believe that just existance of fastSetValue is not enough… For me having events being fired twice inside setValue just does not make sense from user perspective…

[rosolko]

Ok. In such perspective we should perform “select all” and type a new string then. Not a clean + type.

[asolntsev]

hopefully implemented in https://github.com/selenide/selenide/pull/1787