Reconsider GM.registerMenuCommand (polyfill depends on API that's going away)

[ssokolow]

Because no other browser engine has bothered to support it, Firefox has, for a while now, had an open bug for removing the context menu amending capability that the registerMenuCommand part of the polyfill relies on.

There appears to be someone now interested in getting it "fixed" (ie. removing the support) so it'd probably be a good idea to reconsider GM4 not providing its own support for this.

I make heavy enough use of it for things like launching my configuration UIs that, if no suitable replacement is provided, I'll just have to drop support for GreaseMonkey and instruct users that, for technical reasons, I can only support ViolentMoney and TamperMonkey because I don't consider it acceptable UX to clutter up the site with such "set it once and almost never change it" configuration UI buttons.

[StigNygaard]

+1
I like the HTML 5 Context Menus a lot, but if/when they disappear I too hope to have GM.registerMenuCommand back. I cannot see myself maintain another homemade solution for multi-site userscripts.

[arantius]

Any suggestions for a UI/API that will still exist that you'd like to use?

I guess we'll be forced to register things in the monkey menu?

[ssokolow]

That's the way TamperMonkey and ViolentMonkey do it.

I suppose the other option would be to explore the feasibility of approximating what the polyfill does using browser.menus.create to shove all the userscript-registered menu items into a submenu of the context menu... though that'd be sub-optimal without some way to scope them to contexts since people generally expect the context menu to be contextual.

(And, ideally, it'd still be good to have a way to put "configure this userscript" entries in the monkey menu rather than the context menu, similar to how Firefox's addon manager works.)

That latter one really is an "explore the feasibility" though. It's been so long since I poked at the WebExtensions API that I can't remember its limitations in that respect. (I write userscripts because they're more portable and in protest of mandatory extension signing.)

[eight04]

Here is an older thread:
#2714

[esperecyan]

@arantius

I guess we'll be forced to register things in the monkey menu?

Even if the context menu had not been obsoleted from the spec, using it in place of GM_registerMenuCommand has the following disadvantages:

• It is always inserted into the browser’s context menu, which gets in the way of browsing
• Because it inserts into an unsafe context (DOM of Web page side), could causes privacy and security issues
• Unavailable if the context menu is blocked by the Web page side.

[ssokolow]

Firefox trunk just landed a patch to disable access to <menuitem> with a target release milestone of Firefox 85.

https://bugzilla.mozilla.org/show_bug.cgi?id=1680596#c11

(Specifically, it puts it behind a dom.menuitem.enabled pref which defaults to false.)

[esperecyan]

@arantius The implementation of GM.registerMenuCommand() became an urgent issue.

This API has been implemented in both Violemntmonkey and Tampermonkey, as well as in Greasemonkey 3.x. It is not replaceable in any other way, as mentioned above, and is important for compatibility.

I have address all previous concerns about the implementation in #2770 update. Why cannot that be merged?

[esperecyan]

I rebased #2770 onto the latest master.
It is possible to release Greasemonkey that implements GM.registerMenuCommand().