fix: display empty menu item for non-visible submenus

[codebytere]

Description of Change

Previously, when a context menu was created with a submenu that had no visible MenuItems, the menu item would display and not show anything on hover, which i don't believe to be the most user-friendly behavior:

This PR improves the UX of that scenario by first checking if a submenu has any visible MenuItems, and in the case that it doesn't, it creates a localized MenuItem to indicate that the submenu does not currently have any items with which the user may interact:

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• relevant documentation is changed or added
• PR title follows semantic commit guidelines
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed issue whereby a user was not well informed when interacting with a menu submenu that did not have any visible MenuItems.

[MarshallOfSound]

Do we know what the behavior is on Linux / Windows (with SimpleMenuModel)?

[MarshallOfSound]

💯

[release-clerk]

Release Notes Persisted

Fixed issue whereby a user was not well informed when interacting with a menu submenu that did not have any visible MenuItems.

[trop]

I have automatically backported this PR to "4-0-x", please check out #16847

[trop]

I have automatically backported this PR to "5-0-x", please check out #16848

[sindresorhus]

I think it would be better to disable the menu if its submenu has no visible items. Even if you disagree, the menu label should at least be (empty) => (Empty).

[codebytere]

@sindresorhus this mirrors behavior on macOS itself, and was directly lifted from Chrome, capitalization included:

[sindresorhus]

this mirrors behavior on macOS itself

I have never seen this behavior outside of Chrome. Example?

and was directly lifted from Chrome, capitalization included:

Chrome doesn't have a good track record at following native UI conventions.

[nornagon]

This is not the native behaviour of macOS, e.g:

I'm somewhat ambivalent as to whether we should show the (empty) item anyway. On the one hand, it does seem like a better UX. On the other hand, it makes it impossible to match native behaviour.

[sindresorhus]

I wouldn't use iTerm as an example of good macOS UX.

A better example:
Go to Finder, open the "Go" menu, then "Recent Folders", click "Clear Menu", then open "Go" again, and you'll see that "Recent Folders" is disabled. So Apple is doing what I argued for in #16832 (comment).

[MarshallOfSound]

Even Apple aren't consistent with their UX for this (and a lot of other things). For instance the Safari favorites menu.

Without a strong reference from Apple Human Interface Guidelines this is just going to be an opinionated choice, especially if Apple themselves aren't consistent here 😄

[sindresorhus]

@MarshallOfSound That seems like a bug. Notice how the title is also not titleized and the title should have been something like "No Favorites". I'll report it later. Most likely, no one at Apple noticed, as it's very unlikely not to have a single Favorite.

Another example, from Safari (History menu), of the menu being disabled when there are no items:

[sindresorhus]

Although, users should prefer adding a descriptive menu item instead:

Which, IMHO, the Electron docs should recommend.

I think the best default behavior is to disable the owner of the empty submenu.