Bug 244202 – Incorrect IntlBackslash/Backquote for ISO keyboards on macOS

• Status: NEW
• Component: UI Events

[Pierre Ossman]

macOS has an annoying misfeature that it swaps the scan codes for the keys kVK_ANSI_Grave and kVK_ISO_Section when the keyboard is identified as a ISO layout (as opposed to an ANSI layout). This misfeature leaks down to WebKit/Safari and results in the KeyboardEvent code field for the keys Backquote and IntlBackslash getting swapped.

This is problematic for applications such as noVNC that want to keep track of the correct physical keys and will confuse users when using Safari.

Note that Firefox and Chrome both work, so they have some fix for this. I found this bug report for it for Chrome:

https://bugs.chromium.org/p/chromium/issues/detail?id=600607

[Pierre Ossman]

You can easily test the behaviour here:

https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html

[Alexey Proskuryakov]

Thank you for the report. Can you share steps to reproduce the issue?

It is not obvious to me what "correct physical keys" refers to, as ISO and ANSI keyboards are physically different.

[Pierre Ossman]

Go to the above site and press the top left key (left of "1"). On all layouts, this should produce an event with "code" set to "Backquote". This currently works for ANSI layouts (and JIS?), but not ISO layouts.

On ISO layouts, there is an extra key between the left shift and the first character key (usually "Z"). Pressing this key should produce an event with "code" set to "IntlBackslash", but currently does not.

[Alexey Proskuryakov]

The key to the left of "1" on ISO keyboards is NOT the backquote, so I don't understand why you are saying that it should produce the "Backquote" code.

Same with the key to the right of Shift, it's not any kind of backslash.

So I'm still confused about what the user observable issue is, and why it's a WebKit bug.

[Pierre Ossman]

This is about the "code" field, not "key". So the generated symbol isn't terribly interesting.

How the events for these keys should look like is already well established. The standard¹ even has pictures. And every other browser follows it, so it's fairly clear that Safari/WebKit is doing things incorrectly.

¹ https://www.w3.org/TR/uievents-code/#key-alphanumeric-writing-system
  https://www.w3.org/TR/uievents-code/#keyboard-102

As for practical effects, it only affects pages that care about physical keys, rather than symbols. So likely games and remote desktop clients. Which is why we're filing this report. If you press these keys in noVNC, the wrong key is sent to the server, and the wrong symbol is generated in the remote session. E.g. you get a "<" instead of a "§" on a Swedish keyboard.

[Radar WebKit Bug Importer]

<rdar://problem/99277359>