I have a “cross-platform written” 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 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 don’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.
I’m thinking about making a feature request in Bugzilla for this, but thought I wanted to hear if others had an opinion about this? Or maybe somebody know the exact story about “contextMenus” vs “menus”?
PS. Right now my extension is an MV2 extension. But I’m pretty sure the problem is the same when migrating to MV3 (which I probably won’t do until Firefox supports background service workers - or else I have another issue requiring build-script or multiple branches to solve).