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.
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, optionalcode 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.
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
codeproperty ofKeyboardEvents only works for US users and developers cannot test for international keyboard layouts.Requirements
When coming up with solutions, the following requirements were imagined:
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
Cons
Keyboard layout registry
We can add another API that handles registering keyboard layouts with a default to US.
Pros
Cons
codevalue (recommended)We can add an additional, optional
codeparameter 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
codeandkeyto an input source'spressedstate rather than just thekey. Alternatively, we can store thecodeto mimic a real keyboard instead ofkey.Pros
References
CC: @gsnedders, @jgraham, @whimboo