You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The context-menu key from ImGui, Silk.NET, GLFW and SDL ("Menu") is read as Alt, so Shift+Menu is stored as Alt+Shift and clashes with Alt bindings #222
CanonicalizeKey in Keybinding/Models/MusicalTypes.cs (around line 87 at 89f14b9) folds the bare name MENU to ALT:
"OPTION" or "MENU" or "LMENU" or "RMENU" or ... => "ALT",
In Win32 and WinForms, Menu does mean Alt (VK_MENU, Keys.Menu). The frameworks that #209 set out to support use the name for a different key: GLFW_KEY_MENU, Silk.NET Key.Menu, ImGuiKey.Menu and SDL SDLK_MENU are the application / context-menu key. A host that passes key.ToString() from any of these, as #209's folding invites, gets Alt for the menu key without any warning.
Failure scenario
Chord.Parse("Menu") = Alt (equals Alt: True)
bind "context.menu" to Shift+Menu → stored chord = Alt+Shift
bind "menu.bar" to Shift+Alt → context.menu loses its chord (displaced)
press Shift+Menu → executes menu.bar
The user's context-menu binding silently merges with the Alt modifier. Binding Alt+Shift elsewhere removes it, and pressing the menu key runs the Alt command.
This is a name collision between frameworks, not a typo. The WinForms mapping is intentional and tested in Keybinding.Test/KeyAliasEquivalenceTests.cs:40, [DataRow("Menu+A", "Alt+A")], and comes from #166. Those two uses of the name can't both be served by one global alias.
Suggested fix
Keep LMENU/RMENU → ALT, since those are unambiguous, but stop folding the bare MENU, so it stays a key of its own. Add a comment explaining why.
WinForms hosts already have to map Keys.Menu from a KeyEventArgs, where e.Alt is also available. If WinForms support for the bare name matters, document it, or offer an opt-in framework alias table instead of a global fold.
Update the Menu+A test row to match whichever behaviour is chosen.
Acceptance criteria:
Chord.Parse("Shift+Menu") is not equal to Alt+Shift.
Binding Shift+Alt doesn't displace a Shift+Menu binding.
Priority: Medium. Every host built on ImGui, Silk.NET, GLFW or SDL that passes key.ToString() gets this wrong, and nothing warns them. A binding on the context-menu key is silently stored as an Alt chord, displaced by an Alt binding, and runs the wrong command. It needs that key to be bound, though, and there's no data loss.
Decision needed: this is a behaviour change for WinForms hosts that rely on bare Menu meaning Alt. Pick one before implementing: (a) drop the bare MENU fold and document that WinForms hosts map Keys.Menu themselves (the issue's recommendation); or (b) an opt-in per-framework alias table. Option (a) is the smaller change. Either way, keep LMENU/RMENU → ALT.
Activity
matt-edmondson commentedon Nov 5, 2026
Triage
key.ToString()gets this wrong, and nothing warns them. A binding on the context-menu key is silently stored as an Alt chord, displaced by an Alt binding, and runs the wrong command. It needs that key to be bound, though, and there's no data loss.CanonicalizeKeyinKeybinding/Models/MusicalTypes.cs, the key-alias folding from Equivalent key names compare unequal: "Ctrl+Plus" ≠ "Ctrl++", "Ctrl+Comma" ≠ "Ctrl+,", "Back" ≠ "Backspace", and "LWin+A" displays as "A+LWIN" #166/Fold browser, Silk.NET, ImGui, GLFW and macOS modifier names into Ctrl, Alt, Shift and Meta [patch] #209. The fix also needs theMenu+Arow inKeybinding.Test/KeyAliasEquivalenceTests.cschanged.Menumeaning Alt. Pick one before implementing: (a) drop the bareMENUfold and document that WinForms hosts mapKeys.Menuthemselves (the issue's recommendation); or (b) an opt-in per-framework alias table. Option (a) is the smaller change. Either way, keepLMENU/RMENU→ALT.Generated by Claude Code