Move away from KeyboardEvent.key for key bindings?

[marijnh]

Its value isn't specified precisely enough for key combinations involving shift plus other modifiers (some browsers consider such combinations to produce characters, and include the effect of shift, others don't, so Shift-Ctrl-X may yield "x" or "X").

It may be better to go back to using keyCode, which at least reliably identifies the key. That removes support for by-printable-character bindings, but the endless string of issues KeyboardEvent.key has caused in ProseMirror suggests that that may be a reasonable price to pay.

(Possibly we could allow by-printable-character bindings only for bindings without modifiers. But I'm not sure how useful that would be.)

[jasongrout]

We saw similar browser inconsistency issues in Lumino (at least a few years ago, when shortcuts were being developed), and decided to go with .keyCode rather than than .key for shortcuts. If I recall correctly, we even saw inconsistency in a single browser on particular platforms, where going across the number keys with shift, Firefox would show .key as the shifted key for some numbers, but the unshifted key (with shift modifier) for other keys.

[jasongrout]

Here is our unified keycode table for US keyboard layout for various browers, FYI.

[jasongrout]

If I recall correctly, we even saw inconsistency in a single browser on particular platforms, where going across the number keys with shift, Firefox would show .key as the shifted key for some numbers, but the unshifted key (with shift modifier) for other keys.

I just reproduced this on Firefox 71 on macOS 10.14.6. For example, using https://keycode.info/ and using Command Control Shift as the modifier on a US keyboard layout, I get:

physical key	event.key with Command Control Shift modifier	Does .key print the shifted or unshifted key?
`	`	Unshifted
1	1	Unshifted
2	@	Shifted
5	5	Unshifted
6	^	Shifted
7	7	Unshifted
8	8	Unshifted
9	9	Unshifted
0	0	Unshifted
-	_	Shifted
=	=	Unshifted

[marijnh]

See also this spec issue, which doesn't appear to be going anywhere, and this webkit issue where people are, predictably, saying the spec should adjust to what Apple is doing, rather than the other way around.

[marijnh]

I've decided against this—even though it doesn't look like this'll be fixed anytime soon, the situation with keyCode is even worse—that never tells you anything about the character produced by holding shift, so it makes it impossible to bind shifted characters.

My position, then, is to treat this as a kludgey implementation that tries to approach a simple key binding system as closely as it can, but is known to be broken in corner cases due to platform limitations.

[marijnh]

(On the bright side, since the keymap module just another extension, there's always space for implementing a custom approach when you really need it.)