Greasemonkey: 重新考虑 GM.registerMenuCommand（polyfill 取决于即将消失的 API）

+1
我非常喜欢 HTML 5 上下文菜单，但是如果/当它们消失时，我也希望 GM.registerMenuCommand 回来。 我无法看到自己为多站点用户脚本维护另一个自制解决方案。

对仍然存在的 UI/API 有什么建议您想使用？

我猜我们会被迫在猴子菜单中注册东西？

TamperMonkey 和 ViolentMonkey 就是这样做的。

我想另一种选择是探索使用browser.menus.create将所有用户脚本注册的菜单项推送到上下文菜单的子菜单中来近似 polyfill 所做的事情的可行性......尽管那是子菜单由于人们通常希望上下文菜单具有上下文，因此无需某种方式将它们范围限定为上下文是最佳的。

（而且，理想情况下，有一种方法将“配置此用户脚本”条目放在猴子菜单而不是上下文菜单中仍然很好，类似于 Firefox 的插件管理器的工作方式。）

后一个确实是“探索可行性”。 我已经很久没有关注 WebExtensions API 了，以至于我记不起它在这方面的局限性。 （我编写用户脚本是因为它们更便于携带并且是为了抗议强制扩展签名。）

这是一个较旧的线程：
https://github.com/greasemonkey/greasemonkey/issues/2714

@阿兰提乌斯

我猜我们会被迫在猴子菜单中注册东西？

即使上下文菜单没有从规范中被淘汰，使用它代替 GM_registerMenuCommand 也有以下缺点：

• 它总是被插入到浏览器的上下文菜单中，这会妨碍浏览
• 因为它插入到不安全的上下文（网页端的 DOM）中，可能会导致隐私和安全问题
• 如果上下文菜单被网页端阻止，则不可用。

Firefox 主干刚刚发布了一个补丁，以禁用对<menuitem>访问，目标发布里程碑为 Firefox 85。

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

（具体来说，它把它放在dom.menuitem.enabled pref 后面，默认为 false。）

@arantius GM.registerMenuCommand() 的实现成为一个紧迫的问题。

此 API 已在 Violemntmonkey 和 Tampermonkey 以及 Greasemonkey 3.x 中实现。 如上所述，它不能以任何其他方式替换，并且对于兼容性很重要。

我已经在https://github.com/greasemonkey/greasemonkey/pull/2770更新中解决了之前所有关于实施的担忧。 为什么不能合并？