Open Bug 1419394 Opened 2 years ago Updated Last year

WebDriver:ElementSendKeys synthesizes an extra "select" event even without any selection being made

Categories

(Testing :: Marionette, defect, P2)

defect

Tracking

(Not tracked)

People

(Reporter: whimboo, Unassigned)

References

(Depends on 1 open bug, Blocks 3 open bugs)

Details

Here the sequence of events for form elements when using `send_keys("F")`:

        {
          "type": "focus",
          "keyCode": null,
          "content": ""
        },
        {
          "type": "keydown",
          "keyCode": 70,
          "content": ""
        },
        {
          "type": "keypress",
          "keyCode": 0,
          "content": ""
        },
        {
          "type": "input",
          "keyCode": null,
          "content": "F"
        },
        {
          "type": "keyup",
          "keyCode": 70,
          "content": "F"
        },
        {
          "type": "select",
          "keyCode": null,
          "content": "F"
        }

Following keys do not cause a `select` event to be fired anymore. This event should only be fired if a selection is getting changed:

https://developer.mozilla.org/en-US/docs/Web/Events/select

This might need bug 1418995 being fixed first.
[Mass Change 2018-01-15] Moving bugs to backlog
Priority: -- → P3
Can you think of any reason why a select event is fired?  I also don’t understand the relationship to keyCode 0?
Blocks: webdriver
Flags: needinfo?(mjzffr)
OS: Unspecified → All
Priority: P3 → P2
Hardware: Unspecified → All
Summary: send_keys() synthesizes an extra keyCode of 0 for some events (keypress) → WebDriver:ElementSendKeys synthesizes an extra keyCode of 0 for some events (keypress)
Version: Version 3 → Trunk
I don't know in what context this sendKeys call is being made, but maybe the element we're sending the keys to (an input, say) is being clicked or double-clicked in before or after sendKey that causes all the input text to be selected? I don't know of any reason why event.js would synthesize a select out of the blue.

As for keyCode 0, I don't this this is related to the select behaviour. By default it seems that Firefox produces a keypress with keyCode 0 (for printable characters only, I believe). Try it for yourself at https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html
Flags: needinfo?(mjzffr)
Thanks for the link to that key record, it was very useful!  So
Firefox produces keyCode 0 for all keypress events, and this is
expected.

keyCode 70 I believe is "F".  Why would we expect the select event
to fire on typing an upper-case "F"?
Flags: needinfo?(hskupin)
According to https://developer.mozilla.org/en-US/docs/Web/Events/select
the select DOM event fires when something is being selected using
a pointer or shift + arrow keys.  I imagine this could occur if we
call focus() on the element after interaction?  That would explain
why we’re no longer sending select.

In any case, I don’t think select is expected for sendKeys("F").
Flags: needinfo?(hskupin)
keyCode is deprecated and shouldn't be used anymore. As such lets just ditch that part of the summary.

In regards of the "select" event this only happens when the window has the focus. If the focus is on a second window, no such event is getting fired.

Here a simplified testcase for Marionette:

>    def test_typing(self):
>        self.marionette.navigate(inline("""<input onselect="alert('select event')">"""))
>        elem = self.marionette.find_element(By.TAG_NAME, "input")
>        elem.send_keys("f")

Note that the same can be reproduced with geckodriver, but in such a case the element has to be focused first. This is all due to bug 1398111.

Also this problem clearly goes away when using actions, and as such lets wait for bug 1418995.
Depends on: 1398111
Summary: WebDriver:ElementSendKeys synthesizes an extra keyCode of 0 for some events (keypress) → WebDriver:ElementSendKeys synthesizes an extra "select" event even without any selection being made
You need to log in before you can comment on or make changes to this bug.