Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send keys with shift toggle is not working for current firefox #387

Closed
lread opened this issue May 11, 2022 · 3 comments · Fixed by #407
Closed

Send keys with shift toggle is not working for current firefox #387

lread opened this issue May 11, 2022 · 3 comments · Fixed by #407

Comments

@lread
Copy link
Collaborator

lread commented May 11, 2022

Currently

Etaoin has an ide test that exercises shift key toggling.
https://github.com/igrishaev/etaoin/blob/e8d77afec20f42be87c974ac5a09d1dbc116cb4d/resources/ide/test.side#L362-L365

The idea is this should effectively send LOGin.
This works fine on Ubuntu on CircleCI.

But...

In local testing I found it to fail on macOS and Windows.

When things work we see log lines that look like this:

INFO  etaoin.ide.api: Command: sendKeys on 'id=simple-input' with value: '${KEY_SHIFT}log${KEY_SHIFT}in' / OK
INFO  etaoin.ide.api: Command: assertValue on 'id=simple-input' with value: 'LOGin' / OK

But I see failures for firefox that look like this:

INFO  etaoin.ide.api: Command: sendKeys on 'id=simple-input' with value: '${KEY_SHIFT}log${KEY_SHIFT}in' / OK
INFO  etaoin.ide.api: Command: assertValue on 'id=simple-input' with value: 'LOGin' / Failed: Assert failed: 
Assert command:"assertValue"
Expected: LOGin
Actual: LOGIN
(= actual-val value)

It seems like the 2nd shift is not acting as a toggle.

So what's up?

I tried experimenting locally with the same Ubuntu docker image we are currently using on CircleCI. This image has the following installed:

  • firefox v83.0
  • geckodriver v0.28.0

Tests still passed when changing geckodriver to v0.29.0 and then v0.31.0 (the current release).

I then decided to bump firefox to v100.0 (current release) and saw the same failure I witnessed locally on macOS and Windows.

I did a little more testing against various versions of firefox on Ubuntu. It looks like things started to go bad in v99.

  • v83.0 released November, 2020 ✅ passed (what we are testing against on CircleCI)
  • v90.0.1 released July, 2021 ✅ passed
  • v95.0.2 released December, 2021 ✅ passed
  • v97.0.2 released February, 2022 ✅ passed
  • v98.0.2 released March, 2022 ✅ passed
  • v99.0.1 released April, 2022 ❌ failed
  • v100.0 released May 3, 2022 ❌ failed (current release)
  • v101.0b4 (beta not released yet) ❌ failed

So...

I was kind of surprised that this issue seems to be in firefox and not geckodriver.

What to do?

I'm not sure, this is a pretty recent change in behavior.
One option is to temporarily adapt the test to pass for firefox and document the potential limitation.

@lread
Copy link
Collaborator Author

lread commented May 11, 2022

I'm kind of wondering if modifier key toggling is generally supported very well.
Does anybody know? If so, please do share!

@lread
Copy link
Collaborator Author

lread commented May 14, 2022

Hmmm... If I look at the current w3c webdriver spec for send keys, I see:

If the key to type is a modifier key then set the relevant attribute on Keyboard Event to true for the rest of this loop.

So maybe firefox is just trying to adhere to the spec.

@lread
Copy link
Collaborator Author

lread commented May 14, 2022

I do see this bug fix for firefox 99.0 (which is when behaviour changed see above).

I think I'll adapt the test to include only one shift modifier.
If we do need to support toggling key modifiers to properly support selenium ide scripts, we can raise that as a separate issue.

lread added a commit to lread/etaoin that referenced this issue May 14, 2022
After I noticed firefox was failing to handle state changes for multiple
key modifiers (e.g. shift key) in our ide tests, I did a little digging
and decided that might be actully adhering to the w3c webdriver spec
(see clj-commons#387 for details).

Closes clj-commons#387
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant