1494661 - "WebDriver:ElementSendKeys" has to support "NULL" key for resetting modifier keys

Status: NEW

(Remote Protocol :: Marionette, enhancement, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

This is not supported yet, and depends on bug 1418995.

Here the statement from the Webdriver spec:

https://w3c.github.io/webdriver/#element-send-keys

> The key input state used for input may be cleared mid-way through “typing” by sending the null key, which is U+E000 (NULL).

Comment 3

[Andrew Nicols]

Is there any chance that this bug could be addressed prior to modifying the command to use action primitives (bug 1418995)?

The dependency (1418995) doesn't seem to be going anywhere and also has a dependency (bug 1365886) which hasn't been updated in three years. He last comment on 1365886 basically says that there is no pressing need for the functionality because element click, and element send keys exist. So it's a circular loop where sendKeys is broken pending a refactor, but the refactor is blocked because sendKeys means that there's no need for the required change in the chrome scope.

Meanwhile this issue has been open for two years.

For others coming to this issue, it is possible to work around it because elementSendKeys sends an implicit NULL at the end of the command which does work and does not print a character. This means that you can split the string on NULL and just send multiple sendKeys commands. Not ideal, but at least it is possible to normalise the behaviour.

This is also a break from the JsonWire behaviour described at https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol#sessionsessionidelementidvalue which states:

Modifier keys (Ctrl, Shift, Alt, and Command/Meta) are assumed to be "sticky"; each modifier should be held down (e.g. only a keydown event) until either the modifier is encountered again in the sequence, or the NULL (U+E000) key is encountered.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

We currently don't have any cycles to work on this bug. Also we cannot forecast when it will be fixed. Sorry.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

See also https://github.com/mozilla/geckodriver/issues/2043 which reports that since Firefox 90 possible workarounds do not work anymore.

We should check if the bug really depends on bug 1418995, and discuss if we should give it a higher priority.