Normally keyboard shortcuts work by virtue of being sent to the window when it has focus. But in the hidden window case, there is no window to have focus.

Next, apparently, keyboard shortcuts in the hidden window on macOS work when the key being pressed is known by macOS in a menu for which the corresponding native widget has been constructed.

This (apparently?) happens automatically for toplevel menus, but not for submenus (and in any case the submenu is initially empty).

Just programmatically creating popupshowing events itself doesn't appear to be sufficient (though it's not clear to me why not...).

I experimented with an entry that we hide when the menu actually opens, and reshow when the menu hides. That sort of works, except then when we reshow it again as the menu hides, the native menu has now been constructed without this entry in it, and so the shortcut stops working if you show the history menu (without opening the "recently closed windows" submenu).

I considered adding a dummy entry just for the hidden window that was visible. That worked but looked odd.

In the end I figured out that a combination of these approaches (namely: dummy entry in the sub menu in the markup, and firing popupshowing on the parent menu) works without any visual changes, though to be quite honest I don't know exactly why.

I wonder what the "ideal" solution to this would look like. We need the native menu system to know about the menu item in the submenu. And we need to tell it about this menu item eagerly: I don't think macOS gives us an event to say "the user pressed a keyboard combination while no windows were open, make sure your menus are up to date before I process this keyboard shortcut". So we need to make sure the native menu system knows about this menu item at the point when the last window is closed. In other words, the part of this patch that triggers a menu update on window close will probably be necessary even if the rest of the system works as expected.

Have you tried sending two popupshowing events? The first directed at the History menu, and the second directed at the Recently closed windows submenu.

Anyway, I think what we want is:

• A way to tell the native menu system about updated submenu items eagerly (and have those updated items be respected for keyboard shortcuts), and
• maybe a way to run the front-end code that updates the menus without dispatching a synthetic popupshowing event.

(In reply to Markus Stange [:mstange] from comment #21)

Have you tried sending two popupshowing events? The first directed at the History menu, and the second directed at the Recently closed windows submenu.

I did try this before, and I just tried it again. It doesn't work. I don't understand why, but if I had to guess, macOS doesn't check for shortcuts after the "fake" popupshowing events, so the trick is having the item with shortcut ready for the first popupshowing event? It's hard to be sure...

Anyway, I think what we want is:

• A way to tell the native menu system about updated submenu items eagerly (and have those updated items be respected for keyboard shortcuts), and
• maybe a way to run the front-end code that updates the menus without dispatching a synthetic popupshowing event.

I'll file these.

https://hg.mozilla.org/mozilla-central/rev/4a8f14cfa665

Verified with 82.0b2 + no more beeps when respecting the note on step 2.