macOS: 8 of 13 Alt(⌥) shortcuts silently run the wrong action (upstream JCEF bug)

[dineug]

Upstream: JetBrains/jcef#46

Symptom

On macOS, 8 of the 13 Alt(⌥) shortcuts do not perform their own action — they silently perform a different action. Nothing appears broken; the wrong thing just happens.

The most visible case: focus a table and press ⌥N to add a table. Instead of a new table, every column of the focused table gets selected.

This only happens with a Latin input source (ABC / U.S.). With the Korean 2-Set input source everything works, which makes it look like an IME problem. It is not.

Affected shortcuts

The upstream bug collapses the code of every ⌥+character keystroke to KeyA, so each broken binding lands on whatever is bound to Alt+KeyA / $mod+Alt+KeyA.

Shortcut	Intended action	What actually runs
⌥N	addTable	❌ selectAllColumn
⌥M	addMemo	❌ selectAllColumn
⌥K	primaryKey	❌ selectAllColumn
⌥Space	tableProperties	❌ selectAllColumn
⌘⌥1	relationshipZeroOne	❌ selectAllTable
⌘⌥2	relationshipZeroN	❌ selectAllTable
⌘⌥3	relationshipOneOnly	❌ selectAllTable
⌘⌥4	relationshipOneN	❌ selectAllTable
⌥A	selectAllColumn	✅ correct — but only by coincidence, since the corrupted value is KeyA
⌘⌥A	selectAllTable	✅ same coincidence
⌥Enter	addColumn	✅ routed through a getKeyCode() special case upstream
⌥Backspace	removeColumn	✅ same
⌥Delete	removeColumn	✅ same

Bindings are from erd-editor/packages/erd-editor/src/utils/keyboard-shortcut/index.ts.

Cause

Not our code, and not the IntelliJ Platform. It is in the JCEF native glue bundled with JetBrains Runtime — native/keyboard_utils.cpp derives the macOS native_key_code from the character rather than the physical key, then coerces the "unknown" sentinel -1 to 0, which is a real virtual key code (kVK_ANSI_A).

On a Latin layout ⌥ rewrites the character to something non-ASCII (⌥M→µ, ⌥K→˚, ⌥1→¡), which falls outside the lookup table's U+000A–U+007E domain — hence -1, hence KeyA. The Korean 2-Set layout's Option layer emits plain roman letters, so it passes through correctly. Full analysis, disassembly and UCKeyTranslate measurements are in the upstream issue.

Two consequences for us:

• No webview-side fix is possible. The corruption happens inside the IDE JVM, so Chromium only ever sees a synthetic NSEvent with keyCode: 0. event.key, event.code, event.keyCode and event.which are all consistently wrong by the time JS runs.
• No Registry workaround. Both in-process and out-of-process JCEF call the same native function.

Options

1. Rebind away from Alt+character/digit via editor.setKeyBindingMap in packages/intellij-webview. Cheapest and fixes it for every affected IDE version, but diverges from the web/VS Code builds' shortcuts.
2. Register IntelliJ AnActions and dispatch over the bridge. More work, but the shortcuts become IDE-native and user-remappable in Keymap settings — and it sidesteps the ⌥Space conflict with IntelliJ's QuickImplementations as a bonus.
3. Wait for the upstream fix. Even if it lands, it ships in a new JBR, so users on our pluginSinceBuild = 252 floor stay broken for a long time. Not viable on its own.

Reproduce

1. macOS, input source set to ABC or U.S.
2. Open any .erd / .erd.json file
3. Focus a table, press ⌥N

Expected: a new table. Actual: all columns of the focused table get selected.

Background notes on this bug already live in AGENTS.md under the JCEF Gotchas section.