Greasemonkey: GM.registerMenuCommandを再検討してください（ポリフィルは廃止されるAPIに依存します）

+1
私はHTML5コンテキストメニューが大好きですが、それらが消えた場合は、GM.registerMenuCommandを元に戻したいと思っています。 マルチサイトのユーザースクリプト用に別の自家製ソリューションを維持しているとは思えません。

まだ存在しているUI / APIについて、使用したい提案はありますか？

猿のメニューに登録せざるを得ないと思いますか？

これがTamperMonkeyとViolentMonkeyのやり方です。

他のオプションは、 browser.menus.createを使用してポリフィルが行うことを概算して、ユーザースクリプトに登録されたすべてのメニュー項目をコンテキストメニューのサブメニューに押し込むことの実現可能性を調査することだと思います...人々は一般的にコンテキストメニューがコンテキストであると期待しているため、コンテキストにスコープを設定する方法がなくても最適です。

（そして、理想的には、Firefoxのアドオンマネージャーの動作と同様に、コンテキストメニューではなくモンキーメニューに「このユーザースクリプトを構成する」エントリを配置する方法があるとよいでしょう。）

後者は実際には「実現可能性を探る」ことです。 WebExtensions APIを突っ込んでからかなり長いので、その点での制限を思い出せません。 （私はユーザースクリプトを書いています。なぜなら、それらはより移植性が高く、必須の拡張機能署名に抗議しているからです。）

これが古いスレッドです：
https://github.com/greasemonkey/greasemonkey/issues/2714

@arantius

猿のメニューに登録せざるを得ないと思いますか？

コンテキストメニューが仕様から廃止されていなくても、GM_registerMenuCommandの代わりに使用すると、次の欠点があります。

• それは常にブラウザのコンテキストメニューに挿入され、ブラウジングの邪魔になります
• 安全でないコンテキスト（Webページ側のDOM）に挿入されるため、プライバシーとセキュリティの問題が発生する可能性があります
• コンテキストメニューがWebページ側でブロックされている場合は使用できません。

Firefoxトランクは、Firefox 85のターゲットリリースマイルストーンで<menuitem>へのアクセスを無効にするパッチをリリースしました。

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

（具体的には、デフォルトでfalseに設定されているdom.menuitem.enabled設定の背後に配置されます。）

@arantius GM.registerMenuCommand（）の実装が緊急の問題になりました。

このAPIは、ViolemntmonkeyとTampermonkeyの両方、およびGreasemonkey3.xに実装されています。 上記のように、他の方法で交換することはできず、互換性にとって重要です。

https://github.com/greasemonkey/greasemonkey/pull/2770アップデートで、実装に関するこれまでのすべての懸念に対処しました。 なぜそれをマージできないのですか？