1828176 - Unify "contextMenus" and "menus" as true aliases - both supporting getTargetElement() and related

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, enhancement)

Description

[Stig Nygaard]

I have a “cross-platform written” (not browser specific) webextension that can make use of OnClickData.targetElementId and menus.getTargetElement() to find the DOM-element a context-menu was opened from. The webextension also works if this ain’t supported, but takes advantage of it when it is supported.

Unfortunately - to make webextension "cross-platform" - this means that I need to ask for permission for both the menus and the contextMenus API/namespaces in my manifest.json, which gives me a problem if I try to submit my webextension to Chrome webstore because Google doesn’t allow you to request unknown permissions. And in Chrome-land the menus API is unknown.

I wonder if there are any specific reason why browser.menus are a superset of browser.contextMenus, instead of just letting menus and contextMenus being true aliases? I vaguely remember some talk of an attempt to standardize menu-handling in the menus API instead of contextMenus. But if that is (was) true, I think that plan has been cancelled?

I endorse the simplicity (and possibility) of being able to create a cross-platform compatible webextension simply by zipping content of a folder in my repository. It shouldn’t be necessary to use a build-script creating different manifest files (etc) for each browser. And I don’t see any real risk by just adding all functionality from menus to the contextMenus API.

Most of MDN already talks about menus and contextMenus as aliases.

PS. I also raised this issue in Mozilla Discourse, to hear if anybody had some comments to this. But as of writing no comments there (except for a like): https://discourse.mozilla.org/t/113203

Comment 1

[Stig Nygaard]

Or alternatively...
Even if adding only "contextMenus" to "permissions" in manifest.json, you would be granted access to both browser.contextMenus and browser.menus API/namespaces in Firefox.
That would work too.

Comment 2

[Rob Wu [:robwu]]

I implemented menus.getTargetElement in bug 1325814, and initially wanted a separate "menus.getTargetElement" permission, but dropped that in favor of just "menus" because that permission already existed.

I wanted the getTargetElement method to require a new permission because it is available to content scripts. Binding it to the contextMenus permission would cause the contextMenus API to become available in content scripts, in Firefox only. Since contextMenus is cross-browser, I did not want to introduce that divergence.

In retrospect I think that it has been a mistake to introduce the "menus" namespace (originally added because Firefox introduced support for menus that were not context menus). We considered unifying the namespace in bug 1718323, but decided against since there were no upsides to it.

Comment 3

[Stig Nygaard]

(In reply to Rob Wu [:robwu] from comment #2)

Thanks for the explanation. But that's god d*mn frustrating. And a pity MV3 wasn't used as an opportunity to fix that "deadlock situation" (eventually including bug 1527979 too).
So I guess my best change currently is to put my hopes on Google/Chromium adding/accepting the menus API/namespace...

Comment 4

[Rob Wu [:robwu]]

We decided against supporting contextMenus.getTargetElement as an alias for menus.getTargetElement, because that would require the exposure of the contextMenus API to content scripts, which is undesirable as mentioned in comment 2.

(In reply to Stig Nygaard from comment #3)

(In reply to Rob Wu [:robwu] from comment #2)

Thanks for the explanation. But that's god d*mn frustrating. And a pity MV3 wasn't used as an opportunity to fix that "deadlock situation" (eventually including bug 1527979 too).

That's unfortunate indeed.

So I guess my best change currently is to put my hopes on Google/Chromium adding/accepting the menus API/namespace...

That will not happen. Chrome is opposed to supporting menus - https://github.com/w3c/webextensions/issues/188#issuecomment-1315949841