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

Status: NEW

(Remote Protocol :: Marionette, defect, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

+++ This bug was initially created as a clone of Bug #1419393 +++

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

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

Events like `keydown`, `keypress`, and `keyup` should contain the same key code. But this is not the case for `keypress` here. 

This might need bug 1418995 being fixed.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 2

[David Burns :automatedtester]

[Mass Change 2018-01-15] Moving bugs to backlog

Comment 3

[Andreas Tolfsen ❲:ato❳]

Can you think of any reason why a select event is fired?  I also don’t understand the relationship to keyCode 0?

Comment 4

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

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

Comment 5

[Andreas Tolfsen ❲:ato❳]

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"?

Comment 6

[Andreas Tolfsen ❲:ato❳]

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").

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.