Consider align the keycode for '=' in both English and German keyboard.
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
People
(Reporter: sefeng211, Unassigned)
References
(Depends on 1 open bug)
Details
For the '-' key, we dispatch the same keycode, 173.
But why do we dispatch a different one for the '=' key? It's 61 in English keyboard, but 171 in German keyboard.
This may also fix bug 1895725.
Which platform? macOS?
Basically, we use ASCII char which is introduced without Shift or with Shift if a Unicode character is introduced without Shift. Then, compute the keycode from the ASCII char.
The keyCode value is unfortunately an arbitrary number, not a meaningful number and the values are not compatible if the active keyboard layout is not for only ASCII char input, especially on non-Windows platforms. So, first, web apps should use .key or .code instead. Otherwise, they still need to use .keyCode, they need to make global constants and use them on each browser. Once we change the value, such web apps may be broken, so, I think that we should not touch .keyCode anymore.
|
Reporter | |
Comment 2•1 year ago
|
||
The webcompat bug for Google doc was for Windows.
Yeah, I totally agree that web sites shouldn't rely on keycode, and changing it may break sites. However, I do want to point out that I think there's a tradeoff here, maybe at some point we should align with Chrome if that will bring us better web-compat support.
|
||
Comment 3•1 year ago
|
||
I think it would be valuable to be able have the behaviour configurable by origin. That way at least when we spoof the user agent as Chrome for webcompat reasons we can make sure our keycode behaviour matches Chrome.
|
||
Comment 4•1 year ago
|
||
Google Docs suggests S2-ish, but since this does not appear to be about editing functionality on Google Docs and there's other UI for reaching the function, setting S3.
Yeah, I thought that if we add Window.requestCompatKeyCode() and once it's called, KeyboardEvent.KeyCode() can compute similar keyCode value to Chromium.
We can know how Chromium maps keyCode values on non-Windows platform:
- https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/keyboard_event.cc;l=129-131;drc=7c2b25f6a19cfeeea67f0f43ed33617840bab33d
- https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/public/common/input/web_keyboard_event.h;l=23-31;drc=7c2b25f6a19cfeeea67f0f43ed33617840bab33d
- https://source.chromium.org/chromium/chromium/src/+/main:ui/events/keycodes/keyboard_codes_posix.h;drc=21ff30c4da2ff5dc5c05ee22a1993475c29def8e
However, the ideal fix this issue is, we should suggest a new KeyboardEvent attribute which returns a string value which represents the key what Chromium's .keyCode value means with clear definition.
Description
•