The webdriver keys request is problematic because it takes virtual key codes encoded as a string. It looks like one can pass in arbitrary text, and the webdriver implementation might try to honor that, but the spec is clear that it is a sequence of virtual key presses, not characters. For example, by spec, <shift>1<shift> should type ! on a US keyboard, making typing dependent on the keyboard layout.
This change updates the API to make it easier to fall in the pit of success: we keep supporting an explicit rawValue overload that exposes the underlying protocol encoding, but we make it easier to use a KeyCode-based API which calls out the limitation, and offer a helper to build a KeyCode sequence based on Windows alt+numpad codes that should result in the same text no matter what the keyboard layout is.
Also removed the sendKeys test based on msinfo32 because with that specific app, the call returns before all characters have been typed, resulting in partial reads and flakiness.
jeffdav
commented
1 year ago
The webdriver keys request is problematic because it takes virtual key codes encoded as a string. It looks like one can pass in arbitrary text, and the webdriver implementation might try to honor that, but the spec is clear that it is a sequence of virtual key presses, not characters. For example, by spec,
<shift>1<shift>should type!on a US keyboard, making typing dependent on the keyboard layout.This change updates the API to make it easier to fall in the pit of success: we keep supporting an explicit
rawValueoverload that exposes the underlying protocol encoding, but we make it easier to use aKeyCode-based API which calls out the limitation, and offer a helper to build a KeyCode sequence based on Windows alt+numpad codes that should result in the same text no matter what the keyboard layout is.Also removed the sendKeys test based on msinfo32 because with that specific app, the call returns before all characters have been typed, resulting in partial reads and flakiness.