1456642 - "WebDriver:ElementClick" does not handle modifier keys

Status: NEW

(Remote Protocol :: Marionette, defect, P3)

Description

[muthuraj90ec]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

Actions builder = new Actions(driver);
builder.moveToElement(el).keyDown(CTRL).build().perform()
//After the above code execution, CTRL should be pressed,

then calling el.click() should simulate a CTRL + mouseclick


Actual results:

Actions builder = new Actions(driver);
builder.moveToElement(el).keyDown(CTRL).build().perform()
//After the above code execution, CTRL should be pressed,

then calling el.click() which translates to interaction.clickElement(el, a11y) (in marionette)
interaction.clickElement() -> seleniumClickElement() does not check if modifier key is pressed or not.


Expected results:

After 
builder.moveToElement(el).keyDown(CTRL).build().perform()

then calling el.click(), should simulate a ctrl + click on the element.

Comment 1

[Andreas Tolfsen ❲:ato❳]

interaction.seleniumClickElement is deprecated and scheduled for
removal.  We don’t expect to accept any patches for it.

How does the situation compare if you use
interaction.webdriverClickElement, e.g. don’t set moz:webdriverClick
to false?

Comment 2

[muthuraj90ec]

(In reply to Andreas Tolfsen ‹:ato› from comment #1)
> interaction.seleniumClickElement is deprecated and scheduled for
> removal.  We don’t expect to accept any patches for it.
> 
> How does the situation compare if you use
> interaction.webdriverClickElement, e.g. don’t set moz:webdriverClick
> to false?

If I use interaction.webdriverClickElement, (when moz:webdriverClick, is true), 
I get the same behaviour, meaning I do not get CTRL + click behaviour, even though Actions builder = new Actions(driver);
builder.moveToElement(el).keyDown(CTRL).build().perform() was executed.

Comment 3

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

I can see that no event properties are passed to synthesizeMouseAtPoint [1] so that's probably the issue. As I understand it the (long-term) plan is to re-implement element interactions with the Actions API, in which case the events will be constructed correctly based on the current input state, etc. In the mean time, one could write a fix for modifier keys in webdriverClickElement.

[1] https://searchfox.org/mozilla-central/rev/36dec78aecc40539ecc8d78e91612e38810f963c/testing/marionette/interaction.js#181

Comment 4

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

Element click isn't using action primitives yet. So moving it over via bug 1490268 might fix this bug.

Comment 5

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

(In reply to Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me) from comment #3)

https://searchfox.org/mozilla-central/rev/
36dec78aecc40539ecc8d78e91612e38810f963c/testing/marionette/interaction.
js#181

The file has moved and is now located at:
https://searchfox.org/mozilla-central/rev/f979f15eaeef504bfdcd27f033323d62b51986cd/remote/marionette/interaction.sys.mjs#181-188,191

But as given we still do not send any modifier state along with the click event.