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

Created on 29 Apr 2020 · 7Comments · Source: greasemonkey/greasemonkey

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.

Source

ssokolow

👍6

All 7 comments

+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.

StigNygaard on 29 Apr 2020

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?

arantius on 29 Apr 2020

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.)

ssokolow on 29 Apr 2020

👍1

Here is an older thread:
https://github.com/greasemonkey/greasemonkey/issues/2714

eight04 on 30 Apr 2020

👍1

@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.

esperecyan on 4 Oct 2020

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.)

ssokolow on 9 Dec 2020

👀1

@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 https://github.com/greasemonkey/greasemonkey/pull/2770 update. Why cannot that be merged?

esperecyan on 9 Dec 2020

Was this page helpful?

0 / 5 - 0 ratings