GeezerVison is showing github.com — Reconsider GM.registerMenuCommand (polyfill depends on API that's going away) · Issue #3078 · greasemonkey/greasemonkey
Reconsider GM.registerMenuCommand (polyfill depends on API that's going away) #3078DescriptionBecause 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. Reacted by Stig Nygaard, Cerberus-tm, eight, SLC, Kagami Sascha Rosylight, chocolateboy and Qussayyon ActivityStigNygaard commented on Apr 29, 2020 +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 commented on Apr 29, 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? ssokolow commented on Apr 29, 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.) Reacted by Matthijs Wensveen eight04 commented on Apr 30, 2020 Here is an older thread:
#2714 Reacted by 100の人 (エスパー・イーシア) esperecyan commented on Oct 4, 2020 @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 commented on Dec 9, 2020 Reacted by 100の人 (エスパー・イーシア) esperecyan commented on Dec 9, 2020 @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 commented on Jan 10, 2021 I rebased #2770 onto the latest master.
It is possible to release Greasemonkey that implements GM.registerMenuCommand(). Reacted by Patrick Westerhoff, Stig Nygaard and chocolateboy Cerberus-tm commented on Jan 18, 2021 Great! I'll postpone updating Firefox until this has been released (no hurry, I often don't update immediately anyway).
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|