Inconsistency: contextMenus/Menus

[erosman]

Inconsistency: contextMenus/Menus

Please note the following inconsistencies in chrome.contextMenus and menus

contexts default

• Chrome & Safari default to ['page']
• Firefox defaults to ['all']

contexts inheritance

Generally, child menus inherit parent's contexts.

• Chrome 'action' child menus do not appear to inherit from their parent's contexts

Unicode support

• Chrome used to fully support Unicode in contextMenus title but not for the last 1-2 years
  e.g. displays U S instead of 🇺🇸 in contextMenus title (as well as action.setBadgeText, action.setTitle)

[xeenon]

Safari defaults to ['page'] like Chrome. We also inherit any parent contexts if the submenu item does not specify any contexts. Emoji's should also be fine in Safari.

[xeenon]

Emoji's do work fine in menu items in Safari.

[carlosjeurissen]

Firefox defaults to ['all']

Using ['all'] as default does not really make sense and seems like not a very conscious decision but the result of the implementation. If changing this in Firefox to ['page'] would lead to backwards compatibility issues, a way to address this could be to in mv4 require to explicitly set the context for top level menus.

Chrome 'action' child menus do not appear to inherit from their parent's contexts

This seems like a bug. Created a crbug for this: https://issues.chromium.org/issues/402806174

Chrome used to fully support Unicode in contextMenus title but not for the last 1-2 years
e.g. displays U S instead of 🇺🇸 in contextMenus title (as well as action.setBadgeText, action.setTitle)

Can not reproduce it. What platform/OS are you using? Emojis display fine for me in Chrome v131 and v135 on macOS Sequoia. They do appear as completely blank in devtools in Chromium tho, while working in Chrome Canary. Opened https://issues.chromium.org/issues/403156532 for this.

[erosman]

Using ['all'] as default does not really make sense and seems like not a very conscious decision but the result of the implementation.

Indeed, it appears to be a consequence of another bug fix.

Can not reproduce it. What platform/OS are you using?

Ubuntu 24.04

[Rob--W]

The latter two of the reported inconsistencies sound like things that belong to Chromium's issue tracker;

on "page" vs "all": As mentioned in the meeting (notes pending publication at #780), Firefox defaults to "page" when there is no more specific context.

But when creating context menus, it defaults to "all", which excludes tools_menu, tab and bookmark. The idea behind excluding these is that extensions designed for Chrome don't suddenly show random menu items in Firefox-specific context areas.

@xeenon @oliverdunk During the meeting I may have expressed the behavior wrongly. I think that I inadvertently said "all = page + tabs, etc.". What I should have said is "all = everything (often page) excluding tabs, tools_menu, bookmark".
Excluding "tab" by default is thus cross-browser compatible.

The relevance of "all" vs "page" is mainly in non-page menus: whether to include the menu in page_action / browser_action / action menu items. I don't think that there is an explicit reason for Firefox to default to "all", other than that it may make sense to show a menu everywhere by default (at the time of the implementation - the fact that tabs etc. were excluded later shows that this thinking was not necessarily right).

The relevance of defaulting to "all" is clearly apparent in the expectation expressed above, and reported at https://issues.chromium.org/issues/402806174 . It is not that Firefox inherits the context, but rather that when not explicitly specified, that a context menu may appear anywhere. And when that context menu is parented to an "action"-specific menu item, that it would therefore only appear in the "action" menu, giving the appearance of inheritance, when in reality it was just a consequence of scoping a context menu to a narrower context through the parent.

[carlosjeurissen]

Created a demo extension showcasing the behaviour:
https://github.com/carlosjeurissen/webext-tech-demo-extensions/tree/main/issues/chromium-402806174-contextmenu-subitems

From this you can figure out currently no inheritance to the parent contexts exists not in Chrome, and also not in Firefox. Submenus default context will be set to the default context of the browser, not to the parent. Thus the reason the submenu appears in Firefox but not in Chrome is due to a different default (['all'] vs ['page]) and has nothing to do with the fallback values for contexts.

Safari however, does seem to fall back to the parentId contexts property. Considering this being the more logical behaviour, @Rob--W @oliverdunk would you be in favour of aligning with the Safari behaviour?

@erosman One more inconsistency is the fact Safari requires host permissions for the page to display the context menu items. While Chrome and Firefox do not require host permissions for displaying the context menu items.

[xeenon]

@carlosjeurissen activeTab is also an option for in-page context menus in Safari.

[erosman]

From this you can figure out currently no inheritance to the parent contexts exists not in Chrome, and also not in Firefox. Submenus default context will be set to the default context of the browser, not to the parent.

Thank you for testing it. The document clearly stated ...

contexts

• if the item's parent has contexts set, then this item will inherit its parent's contexts
• otherwise, the item is given a context array of ["page"].

[carlosjeurissen]

@xeenon had an interesting remark during the 2025-04-24 meeting:
Almost like we want menu items to inherit the context of the submenus

So take the following scenario:
Parent menu has no contexts, while submenus have contexts

The potential behaviour could be to only display the parent menu when any of the submenus contexts match. This would be a breaking change. A potential way to address this would be to set the context as en empty list of contexts like such: [], which would allow extension developers to opt-in to this behaviour.