electron: Menu Accelerators don't follow macOS HIG

I have been messing with NSMenus at the Cocoa level recently. @nornagon you are indeed correct that the system-level “Show Help menu” shortcut (which defaults to <kbd>Cmd + Shift + /</kbd>) is a completely different shortcut from the one that shows in menus (determined by each individual app, but in System Preferences it happens to be <kbd>Cmd + ?</kbd>).

1. In normal circumstances, using the US keyboard layout and with the default “Show Help menu” shortcut, pressing the <kbd>Cmd + Shift + /</kbd> will activate the system-level action to activate the application’s help menu.
2. There also happens to be a menu item in the Help menu whose shortcut has been set to <kbd>Cmd + ?</kbd> by the app developer which would normally be activated by pressing the <kbd>Cmd + Shift + /</kbd> keys. However, since the system handled the event first, the menu item with this <kbd>Cmd + ?</kbd> shortcut is never reached and its action is never triggered.

Now, I’d like to make it very explicit that <kbd>Cmd + Shift + /</kbd> and <kbd>Cmd + ?</kbd> are distinct shortcuts and not the exactly the same.

As demonstrated above, if you change your keyboard layout such that <kbd>/</kbd> and <kbd>?</kbd> are no longer on the same physical key, then you are now able to freely activate either <kbd>Cmd + Shift + /</kbd> or <kbd>Cmd + ?</kbd> as completely separate shortcuts.

This is consistent with the WYSIWYG principle suggested by @alexdima. I would like to make one important addition to that principle though:

If a character that requires the shift key to type (in the current keyboard layout) is shown in a shortcut, then that shortcut implicitly requires the shift key be pressed in order to activate that shortcut, even if the shift key isn’t shown in the shortcut itself.

For example, in the French keyboard layout the <kbd>:</kbd> is an unshifted key, whereas in the US layout it is a shifted key. That means the shortcut <kbd>Cmd + :</kbd> does not require shift when using a French keyboard layout, but does require shift when using a US keybaord layout, even though shift is not part of the shortcut itself.

This also applies to the option key:

In the French keyboard layout, typing the @ character requires the option key to be pressed. Similarly, the <kbd>Cmd + @</kbd> shortcut implicitly requires the option key to be pressed on a French keyboard layout. On a US layout, this shortcut would implicitly require the shift key instead.

I have confirmed all of this by testing on a very primitive Cocoa application with NSMenus.

---

All of that to say: accelerators should be shown in menus the same as they are typed in accelerator strings. If an accelerator string is "CmdOrCtrl+Shift+7" then the menu item should show ⇧⌘7, not ⌘& (no matter the keyboard layout). This also applies to ⇧⌘/ versus ⌘? because they are distinct and different shortcuts.

macOS itself is inconsistent here.

@nornagon The macOS always shows keybindings using the WYSIWIG principle.

The US keyboard layout

If I look at my US keyboard layout and press the keys labeled cmd+shift+/ the action executes, thus the displayed keybinding is correct:

The Spanish ISO keyboard layout

If I look at the Spanish ISO keyboard layout and press the keys labeled cmd+shift+/ the action executes, thus the displayed keybinding is correct:

---

So it looks that Apple is changing the keys to be pressed across keyboard layouts, which makes sense, why not.

But if you please look at #26907, you will see that the bug is about when passing Cmd+Shift+7 as a keybinding to Electron menu items, Electron incorrectly renders this as Cmd+& which makes 0 sense when having the Spanish ISO keyboard, where & is produced by Shift+6, not by Shift+7.