Greasemonkey: GM4.xでのGM_registerMenuCommandの実装を再検討してください

参考までに、 https ： ます。

（eight04）

_arantiusGM_registerMenuCommandがHTML5コンテキストメニューに置き換えられているのを見ました。 GM 4.xに追加する予定はありますか？ 追跡の問題が見つかりません。_

（アランティウス）

_番号。 Greasemonkeyのポリシーは、（長い間）「ユーザースペース」機能を実装しないことでした。 どのスクリプトでもこれを実行できます。または、このポリフィルのような@requireで実行できます。 Greasemonkeyは、スクリプトでこの機能を使用できるようにするために、この機能を構築またはサポートする必要はありません。 ここでのポイントは、ポリフィルが行うことを実行することです。古いバージョンと新しいバージョンの両方のGreasemonkeyと互換性があるようにスクリプトを簡単に更新できるようにします。_

（eight04）

_つまり、GM4が古いGM_registerMenuCommandのようなユーザースクリプトマネージャーのUIからスクリプトコマンドを実行するためのAPIも提供し、GMにHTML5コンテキストメニューAPIがあるかどうかを尋ねないかどうかを意味します。 GM_registerMenuCommandは、スクリプト構成ダイアログを起動するためによく使用されますが、HTML5コンテキストメニューIMHOとしてポリフィルすることはできません。_

_BTW、私はほんの数ヶ月前にHTMLコンテキストメニューを操作するライブラリを作成しました。これは、すでに設定されている場合、ページのcontextmenuプロパティを再利用します。_
_ https://github.com/eight04/GM_context_

（アランティウス）

_GM_registerMenuCommandは、スクリプト構成ダイアログを起動するためによく使用されます。これは、HTML5コンテキストメニューIMHO_としてポリフィルされるべきではありません。

_なぜだめですか？_

（eight04）

_なぜだめですか？_

_1。 コンテキストメニューのコマンドは次のようになります。_

_-指定されたコンテキスト（要素）で機能するアクション。 たとえば、テキストを選択すると、その選択を操作するアクションである「コピー」コマンドが表示されます。_
_-便宜上指定されたコマンドを実行するためのショートカット。_
_「私のユーザースクリプト設定」コマンドは、両方のカテゴリに分類されません。 コンテキストに依存せず、構成にショートカットを使用する必要もありません。_

_2、信頼できません。 ページスクリプトによってブロック/置換される可能性があります。_

（trlkly）

_私は概念レベルの難しさに同意します。 設定にコンテキストメニューを使用する拡張機能はもうありません。 私はたくさんの拡張機能を実行しているので、そうするとすぐにかなり忙しくなります。_

_しかし、私が見る主な理由は、 ChromeがHTML5コンテキストメニューを仕様から削除したことです。つまり、Firefoxからも削除される可能性があります。 使用しているサイトを見たことがないので、存在すら知りませんでした。 アプリは独自に回転し、実際のコンテキストメニューをブロックします（これはほとんどの場合、非常に煩わしいものです。これにより機能が削除されます）_

これは、スクリプトがどのように相互作用するかを考えようとするときに頭痛の種になります。 メニューオプションがあり、そのメニューオプションが何らかのウィンドウ/ボックス/ダイアログ/設定を変更するものを開いたとすると、新しく生成されたウィンドウは「コンテンツスクリプト」コンテキストにあると見なされ、拡張機能にメッセージを送信できますか？ そうでない場合は、設定を変更できるように、どのようにしてメッセージをコンテンツスクリプトに送り返すのでしょうか。

とはいえ、共通のテーマは設定メニューのようです。 メタブロックに静的に定義された構成フィールドがあり、それらが生成され、Monkeyメニューから保存/変更できるようにしたいと思います。 同様にresourceが、行くことによって変更されたMonkey Menu -> Script -> Config -> Items 。

_メタブロックに静的に定義された構成フィールドがあり、それらが生成され、Monkeyメニューから保存/変更できるようにしたいと思います。 リソースに似ていますが、Monkey Menu-> Script-> Config-> Items._に移動して変更されます。

メタブロックで静的構成フィールドを使用すると、制限が厳しすぎるのではないかと心配しています。
たとえば、最初に言及したスクリプトMouseover Popup Image Viewerの場合、
現在の実用的なレイアウト（ドロップダウンメニュー、チェックボックス、スクロールバー付きのテキストボックス、テキストエリア）とは別に、
設定メニューは現在提供しています：

• 設定を（クリップボードに）インポート/エクスポートし、
• 設定内のMPIVリポジトリからルールをインストールします。
• 多くのカスタムホストルールがインストールされている場合は、入力時に検索ルールがあります。
• 入力されたカスタムホストルールが有効なJSONであるかどうかを検証し、有効でない場合は入力行を赤で強調表示します。

さらに、その作成者はセットアップコード全体を書き直す必要があります。

FWIW、 W3CはHTML5からコンテキストメニューを削除し、 それを削除する予定です。

@legnaleurcゴッシュ、それは一部の人々にとって問題になる可能性があります。 完全な素人として、私にはわかりませんが、コンテキストメニュー項目を追加して、を使用する方法を置き換える別の方法を知っていますか？