[w3c/uievents] `key` determination step 4 ("glyph modifier keys" only) discards the platform's command-state mapping on macOS, so `Ctrl`+`Cmd`+key chords report non-Latin characters (Issue #420)

ShikiSuen created an issue (w3c/uievents#420)

**Summary**

On macOS a keyboard layout may define a *command state* — the key map selected while Command is held. It is the platform's own answer to "what character does this shortcut chord mean": Apple ships `Dvorak – QWERTY ⌘` (whose only purpose is that state) and its CJK input-source layouts (`com.apple.keylayout.ZhuyinBopomofo`, `ZhuyinEten`) define it too, and AppKit's menu key-equivalent resolution honours it.
The `key` determination algorithm's step 4 says: *"If the key event has any modifier keys other than glyph modifier keys, then set key to the key string that would have been generated by this event if it had been typed with all modifier keys removed except for glyph modifier keys."* On macOS both Chromium and WebKit implement that by re-translating the key code with Shift/CapsLock only. As a result, `Ctrl`+`Cmd`+`C` on a Bopomofo layout yields `key == "ㄏ"` — the layout's *base-state* character — even though that layout's command state maps the same chord to `c` and the platform resolves a `⌘C` menu shortcut as "c". (`Cmd`-only chords are unaffected in practice, because `characters` is consulted first and does reflect the command state.)

**Request**
Clarify step 4 for platforms that expose a modifier-state mapping for shortcut chords. Either (a) add a note that on macOS the command state must be applied before the remaining modifiers are stripped, or (b) state that the "key string ... with all modifier keys removed except for glyph modifier keys" is to be produced through the platform's *shortcut* resolution for command chords. Interop matters here because shortcut-matching application code (including Electron apps) reads `key`; today's behaviour forces workarounds that push layout letter shapes (e.g. Bopomofo) into user-visible keybinding UI.

**Reference implementations**

* Chromium `ui/events/keycodes/keyboard_code_conversion_mac.mm`: `DomKeyFromNSEvent()` [step 4](https://github.com/chromium/chromium/blob/c50cbaca28ae90f203498eaa8b4ce6b5a121f4da/ui/events/keycodes/keyboard_code_conversion_mac.mm#L877-L884); `NsKeyCodeAndModifiersToCharacter()` [has the `cmdKey`/`controlKey` mappings commented out](https://github.com/chromium/chromium/blob/c50cbaca28ae90f203498eaa8b4ce6b5a121f4da/ui/events/keycodes/keyboard_code_conversion_mac.mm#L256-L263).
* WebKit `Source/WebCore/platform/mac/PlatformEventFactoryMac.mm`: `keyForKeyEvent()` [falls back to `charactersIgnoringModifiers` whenever Control is down](https://github.com/WebKit/WebKit/blob/7cbfa3e8792f0a9164dab133bf3278613b0aa2e1/Source/WebCore/platform/mac/PlatformEventFactoryMac.mm#L259-L300).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/420
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents/issues/420@github.com>