Greasemonkey: フレームで実行

作成日 2017年09月21日  ·  48コメント  ·  ソース: greasemonkey/greasemonkey

今日のGreasemonkey4は、トップレベルのナビゲーションイベントのみを検出するため、すべてのスクリプトに@noframesを効果的に適用します。

最も参考になるコメント

こんにちは、
問題を修正しますか? これはかなり古い欠陥であり、iframe構造に基づくすべてのスクリプトに影響を与えます...

全てのコメント48件

webNavigation.onCommittedは、最初のフレーム作成/ページレンダリングを「認識」しませんが、フレームナビゲーションが最初のページ以外の場所にある場合、リスナーはそれをキャッチします。 オプションにキー'allFrames': trueが含まれている場合、問題は_ある程度_解決されます。 静的htmlページのフレームにはスクリプトが挿入されますが、origin / urlの一致に問題があります。 さらに、Javascriptを使用してフレームが作成された場合、スクリプトは挿入されません。

私が考えることができる最も簡単な解決策は、webNavigation.onCommittedをwebRequest.onResponseStartedに{'urls': ['<all_urls>'], 'types': ['main_frame', 'sub_frame']}フィルターで置き換えることです。

私はいくつかの限定的なテストを行いましたが、それ以上の変更は必要ありませんでした。 フレーム内とJavascriptを使用して作成されたフレーム内でスクリプトを実行することができました。

@arantius @Sxderpからの修正をマージする計画はありますか?

これは、iframeがクロスオリジンオブジェクトであるシナリオに影響を及ぼしているため、これらの特定のiframeでGMを実行せずにあらゆる種類の変更を行うことは不可能です。

ありがとう !

これを逃した、すぐにそれを調べます。

古いスクリプトのテスト中の観察ですが、それが役立つかどうかはわかりません...

与えられたスクリプトは、iframeで動作するはずですが、
ページの変更を実行しているように見えますが、
ただし、変更されていないページに再度更新されます。

ページを非常に速く更新した場合にのみ、ちらつきが表示されます。

古いスクリプトのテスト中の観察ですが、それが役立つかどうかはわかりません...

これは私のパッチですか、それともリリースされたバージョンですか?

うーん、4.0リリースだったと思います...
私は@ 4.1b3でしたが、テストでは、リリースバージョンを再インストールしたことを確信しています(今まで!)

Eselceが説明しているようなiframeについても同じです。 何らかの方法で実行されますが、iframeまたはページが読み込まれた後に停止します。

このスクリプトを挿入すると、1と「self!== top」しか得られません。

console.log('1');
if (self !== top) {
   console.log('self !== top');
   setTimeout(function() {
      console.log('Timeout');
   }, 2000);  
} else {
   console.log('self === top');
}

「タイムアウト」はログに表示されません。すべての関数とバインドもログに表示されません。

4.1b3を使用しています。

QuantumでGM4.0を実行しても同じ問題が発生します。 main.htmlframed.html 2つのページと、すべてのページに読み込まれ、読み込まれたページのURLを出力するGMスクリプトを使用して、非常に単純なダミーの例を作成しました。

ほとんどの場合、私はmain.htmlについての通知しか受け取りませんが、約5%の場合、特にF5を押したままにすると、 framed.htmlについての通知も受け取る可能性があります。

パッチがリリースされるまでGM4.0をiframe内で確実に実行させるためのハックはありますか?

私はちょうどuserscriptsが確実に実行されていることが判明<embed src="...">ではなく、中に<iframe src="..">
私は小さなテストスクリプトを書きました:
https://openuserjs.org/scripts/cuzi/iframe_embed_Test_Greasemonkey_4

詳細:場合によっては、スクリプトがフレーム内で完全に実行されます(ただし、ビューは後でページスクリプトなどによって上書きされます)。
スクリプトの同期部分が終了することがありますが、非同期部分がページアクティビティによって突然中断されます...
願っています、それは助けになります!

これについて誰かもっと情報がありますか?

このスレッドの簡単な要約(問題):

  • ほとんどの投稿を忘れてください、彼らは適用されません
  • おそらく、スクリプトは常に実行され
  • 残念ながら、ページは後で更新されます-レイアウトが再計算され、実行が中止されます
  • これは、ほとんど(完全ではありませんが)スクリプトの非同期部分に適用されます

私はこれらの内部にはあまり興味がありませんが、おそらく誰かが...

一時的な修正として、iframeを埋め込み用に交換しています(スクリプトの例)。これは、トリガーするフレームに対応するスクリプトを取得するために機能します( <embed src="...">が機能することを理解するための@cvziへのクレジット) 。

ViolentmonkeyとTampermonkeyは、埋め込まれたフレーム内で問題なく機能することに注意してください。 VMはオープンソースなので、どうやってそれを行ったのか見てみましょう。

残念ながら、ViolentmonkeyとTampermonkeyは、特殊関数に古いGM_命名スキームを使用しているため、スクリプトはまだ移植できません。

https://github.com/greasemonkey/gm4-polyfill

Tampermonkey => GM。*呼び出し(提供されていない場合)
Violentmonkey => GM。*呼び出し
Greasemonkey -3.17 / FF -56.0 => GM。*呼び出し
Greasemonkey 4.0+ / FF 57.0 + =>組み込みのGM。*呼び出し

// <strong i="11">@grant</strong>        GM.getValue
// <strong i="12">@grant</strong>        GM.setValue
// <strong i="13">@require</strong>      https://greasemonkey.github.io/gm4-polyfill/gm4-polyfill.js
// <strong i="14">@grant</strong>        GM_getValue
// <strong i="15">@grant</strong>        GM_setValue

@Sxderpの修正はメインブランチに組み込まれていますか? そうでない場合は、どうすれば彼のフォークをインストールできますか?

@Sxderpの修正はメインブランチに組み込まれていますか? そうでない場合は、どうすれば彼のフォークをインストールできますか?

  1. いいえ、そうではありません。
  2. 残念ながら、これは私のPRの1つであり、マスターとの同期を維持していないため、リベースされていません。 そのため、ブランチ自体には現在の変更の一部が欠落しています。
  3. また、PRコメントで提案された変更を実装したこともありません。 正直なところ、これらの変更は必須ではありませんが、Mozillaは継続的に問題を解決するため、変更が必要です。
  4. それでも使用したい場合(非推奨)、以下の手順に従ってください。

  1. git clone -b use-on-response-started-for-execute --single-branch https://github.com/Sxderp/greasemonkey.git [1]
  2. ./package.sh実行すると、XPIファイルが作成されます。
  3. Firefoxでabout:configに移動し、 xpinstall.signatures.requiredfalse
  4. Firefoxでabout:addonsに移動し、歯車をクリックして、[ファイルからインストール]を選択します。
  5. 手順2で作成したXPIを選択します。

[1]お使いのバージョンのgitが-bおよび/または--single-branchフラグ(古いバージョンのgit)をサポートしていない場合は、 git clone https://github.com/Sxderp/greasemonkey.gitおよびgit checkout use-on-response-started-for-execute実行できます。

こんにちは、
問題を修正しますか? これはかなり古い欠陥であり、iframe構造に基づくすべてのスクリプトに影響を与えます...

念のため、明日は3月13日です( Firefox 59.0 )...

@Sxderpを参照したい:

webNavigation.onCommittedは、最初のフレーム作成/ページレンダリングを「認識」しませんが、フレームナビゲーションが最初のページ以外の場所にある場合、リスナーはそれをキャッチします。 オプションにキー「allFrames」が含まれている場合:true問題はある程度解決されています。 静的htmlページのフレームにはスクリプトが挿入されますが、origin / urlの一致に問題があります。 さらに、Javascriptを使用してフレームが作成された場合、スクリプトは挿入されません。

実際、(私のシステムでは)リスナーexecuteUserscriptOnNavigationchrome.webNavigation.onCommittedで確実に呼び出されるため、 chrome.tabs.executeScriptInFrameが正しいframeId呼び出されるという証拠があります。 。 なぜこれでフレームに関するすべての問題が解決されないのですか? iframeで反応するのにchrome.webRequest.onResponseStartedは必要ありません! (つまり、イベントに反応しますが、フレームは表示されませんか?)それは間違いなく呼ばれています...

chrome.tabs.executeScriptInFrameframeId既知のバグはありますか? 何年も前に問題がありましたが、現在は修正されています。 all_framesが設定されていないため、 frameIdが有効である必要があります。 オプションmatchAboutBlanktrueすることは重要なようです(そうでない場合、 executeScriptはエラー<unavailable>返しました)が、 about:blank完全には理解していません

何か案は?

特徴? これは最初から欠けている基本機能です...私はそれを誤解したと思います。

@Eselce 、これはずっと前のことで、私が何を言っていたかを完全に覚えているかどうかは試してみます。 さらに、これは、GM3.xフレームマッチングの私の理解が正しい場合にのみ適用されます。 つまり、各フレームの起点とパスを個別に照合して、実行する必要のあるスクリプトを決定します。 親ドキュメントだけではありません。

さて、問題に。 最初のテストを行ったとき、同じオリジンフレームとリモートフレームを持つ静的ページがありました。 最初のページの読み込み時に、 onCommittedコールバックを1回だけ起動することができました。 メインドキュメントに対しては起動しましたが、ドキュメント内の静的フレームに対しては起動しませんでした[1]。 したがって、スクリプトはそれらに挿入されません。

ただし、最初のロード後、フレームの1つをどこかで「ナビゲート」すると、 onCommittedコールバックが呼び出され、スクリプトが新しい場所のフレームに挿入されます。

上記の問題を回避するために、 all_framesオプションキーを使用しようとしました。 キーを使用すると、スクリプトがページ上のフレームに挿入されますが、フレームの起点とパスがスクリプトの実行対象または実行対象外に適切に一致しないという明らかな欠点がありました。

余談ですが、 all_framesキーを使用しても、Javascriptで作成されたフレームにスクリプトが挿入されないことにも触れました。

[1]この問題がまだ存在するかどうかはわかりません。 この問題はFF52 ESRには存在しませんでしたが、56(57?)には存在していました(したがってリグレッション)。 おそらくそれは修正されました。

私はほとんどすべての点であなたに同意します。

また、各フレームがタブ全体であるかのように個別に一致するという点で正しいです(フレームに埋め込まれた独自のwindowと独自のdocument )。

ええと、私はほとんどいつも同じメニュー/フレーム構造を使ってきたので、多分私は別のものをテストする必要があります。

「解雇された」と言うとき、それはリスナーの純粋な呼びかけを意味しますか?

私が言ったように、 executeScriptがエラー状態を生成するいくつかの例に遭遇しましたが、リスナーはまだ呼び出されていました。

all_framesことはできない仕事、理由の間違ったlocation (異なるwindow 、異なるdocument )。 ところで:メニューは各タブのメインフレームURLのみを処理します-メニューが間違っている場合、それはスクリプトが呼び出されないという意味ではありません...

「解雇された」と言うとき、それはリスナーの純粋な呼びかけを意味しますか?

その特定のメッセージでは、「 onCommitted.addListenerに渡された関数が呼び出されました」という意味

こんにちは、

この投稿を注意深く読みましたが、ローカルスクリプト「.user.js」で代替ソリューションを使用する方法がわかりません。 どうすればソリューションを適用できますか? すみません、私は新しいです。

(Firefoxを更新してから、生成されたポップアップiframeは追加のスクリプトによって認識されなくなりましたが、同じポップアップを新しいウィンドウで開くと、スクリプトが適用されます。)

よろしくお願いします

あなたは問題が何であるかを正確に説明しました:それは@noframesがアクティブになっているようなものです。 フレームコンテンツのURLがスクリプトを正しくアクティブ化しません。 うまくいけば、これはすぐに修正されます(余分なウィンドウでフレームを開くのは面倒です)...

Eselceに感謝します。
そして、Firefoxのアップデート以来、私は常に、ターゲットサイトですでに使用されているすべてのscipts'.js '(requireを含む)を宣言する義務があります。 (jquerryを含む)
そしてそれは同じではありません....それはバグや衝突を引き起こします。
この問題も知っていますか?

2945には、スクリプトがフレームで開始されたが、数ミリ秒後に破棄されたという観察の別の例が含まれています。

テストしている特定のURLは自分の管理外であるため、提供することを躊躇していますが、一貫性はあるものの奇妙な動作を見つけることができます。

やり取りする必要のあるサイトがあります。 最初に、rows = "100%、0"(画面全体に1フレーム)のフレームセット/フレームを別のドメインにロードします。 このフレームには、中間フレームセット/フレームのドメイン内に1つのフレームセット/ 3つのフレームが含まれています。

1 + 3の子フレームのGMスクリプトの一部は、「ブリップ」して存在し、最初のサイクルの後に消えます。非同期操作の後で戻ることはありません。 これは、このスレッドで説明されているいくつかの動作に適合します。 どちらが「ブリップ」するか、および以下で説明する動作はブラウザ/ GMバージョンによって異なりますが、ランダムではないことに注意してください。 パターンは奇妙ですが、どのような設定でも100%再現可能です。

  1. 最初のフレームセット/フレームは決して存在しません。 最初のサイクルと遅延後の両方で、window.documentとunsafeWindow.documentの両方を使用して、フレームタグをデタッチして再構築しようとしましたが、そのフレームのGMスクリプトがconsole.logに何かを報告することはありません。 ( @includeは*であり、 @ excludeやその他のURLフィルタリングはありません。)
  2. 後の動作の一部はFirefox52.8 / GM4.1@ noframesが設定されているかどうかにincludes *を@ noframesが設定された状態でブリップすることはありません。 window.top!== windowを確認しました。つまり、ブラウザはこれらがフレーム内にあることを認識しています(または認識している必要があります)。
  3. Firefox 52.8 / GM 4.1では、次のフレームセット/ 3フレームは常に存在します。 Firefox 60.0 / GM 4.3では、初期フレームロード時に「ブリップ」しません。
  4. Firefox 60.0 / GM 4.3では、3つのフレームの1つで、3つのフレームの別のフレームをナビゲートするリンクをクリックすると(スクリプトではなく、アンカーリンクの「target」属性を介して)「ブリップ」します。新しいURLではなくナビゲートされたフレームの古いURL。 (これは、アイテム#3の初期ロード時にブリッピングしたフレームの1つです。)
  5. これが最も奇妙な部分です。 両方のブラウザ設定で---手順に従って、2層のフレームセット、合計4つのフレームで最初のページを開き、1つのフレーム内のリンクをクリックして、同じページ上の別のフレームをナビゲートしました。 これに名前を付けるために、最初に表示された第2レベルのフレームセットには、フレーム「top.htm」、「menu.htm」、および「start、htm」がありました。 「menu.htm」フレームのリンクをクリックすると、「start.htm」を保持しているフレームが「content.htm」に移動します。上記のように、ブラウザの設定ごとに動作は似ていますが、わずかに異なります。 次に、「content.htm」フレーム内のリンクをクリックして、同じフレーム、同じドメイン内を移動します。

この時点で、「content.htm」のスクリプトは「ブリップ」するだけでなく、GM.xmlHttpRequestが完了した後も存続します(非同期イベント)。 この時点で、「content.htm」はブラウザディスプレイのどこにもありませんが、そのスクリプトは引き続き動作します。

したがって、フレーム内のページのGMスクリプトが機能しない理由は、スクリプトがページのロードではなくページのアンロードでロードされているためであるように思われます。 @ run-atをdocument-startに設定し、スクリプトをunsafeWindow.documentのDOMContentReadyイベントに配置しても、改善はありませんでした。 (window.documentに設定すると、イベントが発生することはありません。)

-ライアン

Firefox 52.8 / GM 4.1では、次のフレームセット/ 3フレームは常に存在します。 Firefox 60.0 / GM 4.3では、初期フレームロード時に「ブリップ」しません。

Firefox 57への移行で、Mozillaは_何か_を変更しました。 それが何であれ、フレームがトリガーされる方法が変更されました(または壊れました)。 これは他の問題で簡単に話されました。 その結果、スクリプトは初期フレームロード(57+)では実行されませんでした。

最終的にuserScriptまたはcontentScript APIに切り替えると、とにかくこれらすべてが解決されるはずです。

だから人々は言い続けます、それでもViolentmonkeyはフレームで実行し続けます。 VMはユーザースクリプトをWebページのコンテンツから適切に分離しません(CSPはユーザースクリプトをブロックし、Webページはグローバルオブジェクトを書き換えることができます)、または私はずっと前にGreasemonkeyをチャックしていました。 おそらくこれらは関連する問題ですが、私はuserscriptエンジンを使用しているので、Firefoxのクロムを自分で見つけるのに十分な深さで探索する必要はありません。

うーん、これは難しい問題です。一部のスクリプトは、iframeで機能しないため、機能しなくなりました。 それで、それを修正することは実際には不可能であるように思われます、そして私たちはMozillaにいくつかのAPIを実装する方法をとらなければなりませんか? 回避策のように、自分たちでできることは何もありませんか? 多くの場合、同じドメインからでも、iframe内のページにいくつかの処理を行う必要があります。

今のところ私自身の回避策は、トップフレームでGreasemonkeyを実行し、子フレームでViolentmonkeyを実行することです。 自家製のライセンスがあいまいなため、Tampermonkeyを使用できませんが、それが問題にならない場合は、うまく機能する場合と機能しない場合があります。

VMはスクリプトをページ自体のコンテキストにドロップすることに注意してください。 これは、安全な同等物がないGMのunsafeWindowのようなものです。 私が経験した最も記憶に残る時間の1つは、ページコンテンツがArray.prototypeで 'toJSON() "メソッドを定義し、JSON.stringify()がスクリプト内で無効なJSONを吐き出すスクリプトをデバッグすることでした。私が見つけたので、これらを防御的にトラップして修正します。

VMに関するもう1つの大きな懸念は、コンテンツページのcontent-security-policyを尊重することです。そのため、スクリプトソースを制限するディレクティブがあると、VMスクリプトが実行されなくなります。 これはブラウザコンソールで確認できます(ただし、Webコンソールでは確認できません)。 そのため、VMを完全に実行して、GMを削除することはできません。 CSPセットを使用した子フレームにはまだ遭遇していませんが、遭遇すると完全に使用できなくなります。

@RyanHanekampヒントをありがとう! おそらく、いくつかのスクリプトにViolentmonkeyを使用します。

Violentには同期GM_getValueのようなものもありますか? これは、新しいGreasemonkeyの大量のスクリプトを壊すもう1つの問題のある問題です。 ただし、さまざまな理由から、Greasemonkeyを今でも最も信頼しているので、そのままにしておきません。

iframeに関しては、次のように、Javascriptを使用して直接アクセスできるオブジェクトタグに置き換えようとしています。

myObject= document.createElement('object');
myObject.setAttribute('id', 'myObject'); 
document.body.appendChild(myObject);
myObject.setAttribute('src', 'https://example.com');

次に、オブジェクトがロードされると、次のようになります。
document.querySelector('#myObject').contentDocument.defaultView.document.querySelectorAll('someElementInsideObjectPage')
少なくともこれは、オブジェクトがメインページと同じホストにあるスクリプトで機能します。 オブジェクトとの間でメッセージを送信することもできます( ... contentDocument.defaultView.postMessage('hello, object') )。

私はVMの専門家ではありませんが、少なくとも元のGM_ * APIのほとんどを実装していると思います。 ただし、長期的には同期プラットフォームに戻るよりも、スクリプトを非同期に適応させる方がよいと思います。 私の理解では、Greasemonkeyは、バックグラウンドスクリプトとコンテンツスクリプト間の同期呼び出しを許可しない新しいQuantumフレームワーク内のパフォーマンス向上としてこれを行いました。

オブジェクトの解決策に関しては、それは私の特定の問題を解決しませんが、他の人がそれを有用だと思ってくれてうれしいです。 CSS /プロパティなどをマーシャリングしてフレームやiframeで機能させる以外に、キャプチャプロセスでオブジェクトを潜在的に危険なものとして除外する必要があります。 これらすべての問題を回避する方法はいくつかありますが、GMが最終的に缶に書かれていることを実行するまでは、VMの方が暫定的でした。

また、同一生成元のフレーム/ iframeがある場合は、それらのコンテンツに直接アクセスすることもできます。 難しい部分はクロスオリジンです。そのため、フレーム内にユーザースクリプトが必要です。 親ウィンドウと通信するためにwindow.postMessage()チャネルを設定します。

@RyanHanekamp ViolentMonkeyにはまだ古くてシンプルなGM_ *があることを知って

暴力があなたにとってより良い選択肢だった理由を理解しています。 AnthonyやSxderp、または他の誰かがこれを最終的に実装する方法を見つけてくれることを期待しましょう。 私は本当に貢献できればいいのですが、私は完全な素人です。

ああ、同一生成元のiframeのコンテンツに直接アクセスできますか(postMessageなどなしで)? 方法を探すのに多くの時間を費やしたことを覚えていますが、それは不可能だったようです。 そのため、私もpostMessageに切り替えました。

フレームとiframeには、windowプロパティと同等のcontentWindowプロパティがあります。 どちらにも、DOMにアクセスするためのドキュメントプロパティがあります。

(同じオリジンで)iframeを操作する上で最も難しいのは、コンテンツが読み込まれるタイミングを検出することです。これは、スクワットが発生するまでスクワットを実行できないためです。 onloadは見た目どおりに機能しません。 Firefoxは、孫/ひ孫などのフレームを含む、ロードされたすべてのフレームに対して発生するDOMFrameContentLoadedイベントを提供します。これは、event.targetプロパティを使用して元のフレーム/ iframe要素と照合できます。 フレーム/ iframeのコンテンツを制御する場合は、postMessageを使用するか、window.parentオブジェクトのグローバルメソッドを呼び出して、親と通信することもできます。

そういえば...それはこの問題の潜在的な回避策です。 GMスクリプトをコーディングして、ユーザースクリプトをクロスドメインウィンドウ参照に手動で挿入する方法がある場合、またはその可能性がある場合は、ユーザースクリプトの作成者にとってより多くのコーディングが必要になりますが、作業は完了します。 パターンはDOMFrameContentLoadedをリッスンし、event.targetが第1世代であるかどうかを確認し、第1世代である場合は手動でスクリプトを挿入します。 (第1世代のフレームのスクリプトが第2世代のフレームのDOMContentLoadedをリッスンできるため、完全なチェーンを取得できると想定しています。)@ run-at dom-startの動作を取得する方法はなく、タイミングの問題もある可能性があります。しかし、おそらくほとんどのユースケースでそれらを回避することができます。

私はこれまで解決されてきたこの問題を個人的にあきらめ、代わりに拡張機能を直接コーディングすることに移りました。 これはすべてのフレームで正常に機能します!

この点でのGreasemonkeyとViolentmonkeyの違いは、Violentmonkeyがall_framesがtrueに設定されたコンテンツスクリプトからトリガーされているのに対し、Greasemonkeyにはインストール時のコンテンツスクリプトがなく、バックグラウンドスクリプトの疑わしい機能に完全に依存していることです。タブのフレームがナビゲートされました。 (そして、Violentmonkeyは、はるかに安全なtabs.executeScript()を使用する代わりに、一時的にSCRIPTタグを挿入するため、CSPページで失敗します。)

all_frames、run_at startを使用して静的コンテンツスクリプトを挿入し、すべてを照合して、start / document.DOMContentLoaded / document.Idleのバックグラウンドプロセスに通知し、各run_atのユーザースクリプトをトリガーします。これで準備完了です。 この問題を解決するための重要な作業量ですが、管理しやすい量です。 自分で修正しますが、開発者の依存関係を調べることに興味はなく、出力コードしか生成できませんでした。

@RyanHanekamp

代わりに、拡張機能の直接コーディングに移りました。 これはすべてのフレームで正常に機能します!

あなたの拡張コードを共有してもよろしいですか?

私の拡張機能は汎用ではありません。 重要なのは、マニフェストでall_urlsを使用して静的content_scriptを使用すると、all_framesは、フレームが読み込まれるかナビゲートされるたびにスクリプトを実行し、ページのContent-Security-Policyに関係なく、/ Functionコンストラクターコードを評価することもできます。

プログラムで作成されたフレーム/ウィンドウでテストしたことはありませんが、run_at設定に関係なく、最初の作成時に実行されると思います。このようなフレームは最初は空白で作成されてから入力されるため、エンジンはおそらく最初の作成のみを認識します。 また、データをテストしませんでした:明示的な一致が必要なURL-all_urlsがそれらをカバーするのか、それともhttp / httpsだけをカバーするのかはわかりません。

静的なcontent_script参照である必要はないかもしれませんが、ページがナビゲートされたときに動的に呼び出されたコンテンツスクリプトが自動的に読み込まれるかどうかは、ドキュメントからは不確かに見えます。 私の印象では、それらは提供された一致パターンに従って現在一致しているタブ/フレームにのみ注入され、ナビゲーションは再注入をトリガーしません。 しかし、この目的で静的content_scriptを使用することにマイナス面はありません。

Greasemonkeyは明らかに、マニフェストに静的リソースとしてuserscriptを含めることができず、コンテンツスクリプトはtabs.executeScriptに直接アクセスできないようです(ただし、私は数日しか経っていないため、これについてはほとんど専門家ではありません)。ただし、静的コンテンツスクリプトで実行できることは、バックグラウンドプロセスにメッセージを送信して、frameIdがナビゲートされたこととどのURLに移動したかを通知することです。 これは、webRequestまたはwebNavigationで適切なイベントをフックするために、このスレッドで言及されている試みをどのように認識するかよりも信頼性が高くなります。 静的content_scriptからのシグナルは、Greasemonkeyのuserscriptローダー/インジェクターをトリガーするために探しているイベントになります。

document_startを厳密に実行しなければならないユーザースクリプトには遅延が生じる可能性があります。 バックグラウンドスクリプトの呼び出しは非同期であり、ユーザースクリプトが呼び出されるまでにドキュメントは進行します。 スクリプトタグの挿入はcontent_scriptから直接同期的に実行できるため、これがViolentmonkeyがtabs.executeScriptの代わりに一時的なスクリプトタグを使用する理由である可能性があります。 run_at document_startのドキュメントの状態の不確実性を回避することを余儀なくされるのは面倒ですが、スクリプトがまったく実行されないよりは望ましいと思います。

Greasemonkey ... [静的コンテンツスクリプトを使用して]バックグラウンドプロセスにメッセージを送信して、frameIdがナビゲートされたこととどのURLに移動したかを通知できます...

これは、私たちが何に使用するのにやる検出するために.user.jsナビゲーションを。 明白で良い解決策のようです:コンテンツスクリプトを実行してコンテンツを検出してください!

しかし、拡張コンテンツスクリプトでさえCSP(#2631およびhttp://bugzil.la/1267027およびhttp://bugzil.la/1411641)によって破壊される可能性があることが判明しました。

次のCSPセットを使用して、Firefox 60.0.1および52.8.1ESRで、content_script内から直接Function()コンストラクターを含む独自のプラグインを実行できます。

frame-srcデータ:; object-src 'なし'; script-src'none '; style-src'unsafe-inline 'データ:; connect-src 'なし'; media-src 'なし';

Firefoxが根本的なバグを修正したため、2631は閉じられました。 最初のbugzillaは、content_script自体ではなく、スクリプトタグの挿入(Violentmonkeyメソッド)を参照しています。 2つ目は、CSPのサンドボックス属性を参照するものです。これは、ドメインがそれ自体に対してもドメインの一致を正常に完了しないようにするため、当然のことです。 NaNのようなちょっと!== NaN。

これが数ヶ月前に最初に提出されたとき、私たちは別のことをしました。 今日はwebNavigation.onCommittedを使用して

こんにちは、これは今解決されましたか?

Tampermonkey用に作成したスクリプトをGreasemonkeyを使用してiframeで起動することができませんでした。

実行用のコードは私たちの側では変更されていません。 したがって、Mozillaが彼らの側で何かを変更しない限り、これはまだ壊れています。 ただし、#2663で解決するはずです。

ViolentmonkeyとTampermonkeyは、埋め込まれたフレーム内で問題なく機能することに注意してください。

Tampermonkeyは、少なくとも私にとってはChromeのiframeに問題があります。

ViolentmonkeyとTampermonkeyは、埋め込まれたフレーム内で問題なく機能することに注意してください。

Tampermonkeyは、少なくとも私にとってはChromeのiframeに問題があります。

しかし、FirefoxViolentmonkeyでは機能します。 それで、そこでどのように機能するのだろうか?

古い同期GM_GetValueを使用するスクリプトがViolentmonkeyでも正常に機能することに気づきました。 そんなことがあるものか? Firefoxが非同期GM.GetValueを強制したと思いましたか? 私は今とても混乱しています:おそらくViolentmonkeyは同期や他のものをまだサポートするために何か他のものを犠牲にしなければなりませんでしたか?

@ Cerberus-tm Firefoxでの変更により、データは拡張ストレージまたはバックグラウンドコンテキストから非同期でのみ要求できるようになりました(ユーザースクリプト自体は非同期でコンテンツスクリプトに送信されます)。 ただし、各GM4コンテンツスクリプトがプリフェッチされてコンテンツスクリプトにキャッシュされている場合、そのページにロードされている各ユーザースクリプトに格納されているデータを同期的にユーザースクリプトに提供できます。

このようなキャッシュにより、コンテンツスクリプトはユーザースクリプトのデータ要求に同期的に応答できます。 キャッシュを実装すると、さまざまなコンテンツスクリプト間で一貫性を維持する際に問題が発生しますが、コンテンツスクリプトにGM4の拡張ストレージへのすべての変更をリッスンさせることで解決できます。 さらに、ユーザースクリプトが大量のデータを格納している場合、ユーザースクリプトが実行されるすべてのコンテンツスクリプトにデータをキャッシュすると、各コンテンツスクリプトに必要なメモリも大幅に増加します。

TMとVMは、これらのユーザースクリプトマネージャーがChromeに実装されたときに、元のGreasemonkey APIとの互換性を損なわないようにするために、上記と同様のことを行うことを選択しました。 拡張ストレージなどとの非同期通信。すでにChromeで実行していることを考えると、Firefoxに実装したときに変更する理由はありませんでした。

したがって、WebExtensionsへのFF57カットオーバーは、GMの書き換えを強制しましたが、 GM.getValueGM.setValueなどの非同期APIの採用を強制しませんでした。WebExtensionsは非同期ベースのAPIは、同期よりも実装が簡単ですが、必須ではありませんでした。

個人的には、互換性を壊すための選択やその他の選択は不幸だったと思います。 GM3で正常に実行されたスクリプトとの下位互換性および/またはTMとの互換性がないため、多くの人がGM4を使用しないことを選択しています。 私の経験では、私が使用している30を超えるユーザースクリプトはすべてGM3で正常に機能しましたが、GM4では機能しません(または、少なくともGM4と互換性があるように書き直す前は機能しませんでした)。 私が毎日使用している28のユーザースクリプトがまだありますが、GM3では正常に動作しましたが、GM4では機能しません。

この問題の回避策を、Greasemonkey / ‌Tampermonkey / ‌userscriptをiframeStackOverflowに投稿しました。 基本的に、フレームがロードされるのを待ってから、 window.frames配列を操作しています。 各フレームの本体にカスタムマーカーを使用して、フレームがすでに表示されていることを示します。

おそらくGreasemonkeyは同様の方法でソリューションを実装できますか?

waitForKeyElements()のようなGM.waitFor(css_selector, action_function)もあれば素晴らしいと思いますが、それはさておきです。

このページは役に立ちましたか?
0 / 5 - 0 評価