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

Keyboard Layouts in Webdriver #1743

Open
jrandolf opened this issue Jun 5, 2023 · 0 comments
Open

Keyboard Layouts in Webdriver #1743

jrandolf opened this issue Jun 5, 2023 · 0 comments

Comments

@jrandolf
Copy link
Contributor

jrandolf commented Jun 5, 2023

This issues discusses several solutions to keyboard layouts in WebDriver.

Background

While working on keyboard inputs in Chromium, several reviewers brought up keyboard layout and questioned why webdriver assumes a US layout. For the most part, they were primarily concerned with shortcuts that certain keyboard combinations would trigger (although in webdriver, events are emitted on the page, not at the browser level), but nonetheless confused by the assumption.

Problem

With the current specification, the code property of KeyboardEvents only works for US users and developers cannot test for international keyboard layouts.

Requirements

When coming up with solutions, the following requirements were imagined:

  • All keyboard layouts should be testable (e.g. Dvorak, German, etc).
  • Browser binary size must remain the same

Solutions

Native keyboard layouts

Within Chromium, we have code that can gather information about the current keyboard layout on the device it runs on. This can be used to get the current code. (I assume this is also the case with Firefox and Safari).

Pros

  • Minimal code required.

Cons

  • Testing becomes dependent on the testing OS (maybe a good thing? Otherwise, what's the point of testing different OSes).
  • Potential cross-browser flakiness based on implementation (which can be mixed with OS problems; hard to debug).

Keyboard layout registry

We can add another API that handles registering keyboard layouts with a default to US.

Pros

  • Minimal code on the vendor side.
  • Testing is reproducible across browsers and OSes.

Cons

  • Layout code lives in user-land (which can technically implement the first solution).

code value (recommended)

We can add an additional, optional code parameter to the key action object which is a KeyboardEvent code value specified in https://www.w3.org/TR/uievents-code/. It would default to the US layout.

This change would also require a slight modification of the dispatching mechanism; specifically, we should add the code and key to an input source's pressed state rather than just the key. Alternatively, we can store the code to mimic a real keyboard instead of key.

Pros

  • Minimal code on the both sides.
  • Testing is reproducible across browsers and OSes.
  • No "layout" code required; just use the combination you need.

References

CC: @gsnedders, @jgraham, @whimboo

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

No branches or pull requests

1 participant