Chrome 拡張機能の Persistent Service Worker

Question

webRequest API を使用して特定のリクエストのフォームで渡されるデータをインターセプトするため、Chrome 拡張機能で Service Worker を永続として定義する必要がありますが、その方法がわかりません。すべて試しましたが、Service Worker がアンインストールされ続けます。

ロードを維持し、リクエストがインターセプトされるまで待つにはどうすればよいですか?

Answer 1

chrome.webRequest API とは異なり、chrome.webNavigation API は完璧に機能します。chrome.webNavigation API は Service Worker を起動できるため、これで、chrome.webRequest API API を chrome.webNavigation に組み込むことができます。

リーリー

Answer 2

＃＃＃目次＃＃＃

問題の説明

• ＃＃＃＃＃＃解決：＃＃＃

  • エクスプロイト
•
• オフスクリーン

  API

  •

  ネイティブメッセージング
  API • WebSocket
  API • chrome
  メッセージング API • 専用タブ
  ＃＃＃＃＃＃知らせ＃＃＃
  定義上、Service Worker (SW) は永続化できず、ブラウザは一定時間 (Chrome では 5 分) が経過すると、すべてのアクティビティ/リクエストを強制的に終了する必要があります。非アクティブ タイマー (つまり、そのようなアクティビティが行われていないとき) はさらに短く、30 秒です。

Chromium チーム
• は現在、この動作が

  適切であると考えています (チームは特定の側面を緩和することがあります。たとえば、Chrome 114 は各メッセージの後に chrome.runtime ポートを拡張します)。ただし、これは観察結果が拡張機能ではない場合にのみ適用されます。 1 日に数回しか実行されない頻繁なイベントにより、実行間のブラウザのメモリ フットプリントが削減されます (例: URL を使用した webRequest/webNavigation イベント > めったにアクセスしないサイトのフィルタリング)。これらの拡張機能は、状態を維持するために再設計できます (

  Example
)。残念ながら、そのような牧歌的な生活は多くの場合持続不可能です。

＃＃＃既知の問題点＃＃＃

問題 1: Chrome 106 以前では、webRequest イベントのソフトウェアが起動されません。 他の回答に示されているように、

chrome.webNavigation

のような API をサブスクライブしてみることもできますが、これはワーカー スレッドの開始後に発生するイベントに対してのみ役立ちます。

• 問題 2: スタッフがイベントのためにランダムに起きなくなる。

  解決策は、chrome.runtime.reload() を呼び出すことです。

• 問題 3:

  Chrome 109 以前では、既に実行されているバックグラウンド スクリプトからの新しい chrome API イベント

  のソフトウェア ライフサイクルを延長できません。これは、30 秒の非アクティブ タイムアウトの最後の数ミリ秒以内にイベントが発生した場合、コードは何も非同期で確実に実行できないことを意味します。これは、ユーザーが拡張機能が信頼できないと考えることを意味します。
  質問 4: 拡張機能がリモート接続を維持するか、状態 (変数) の再構築に時間がかかる場合、または次のようなイベントが頻繁に発生する場合、パフォーマンスは MV2 よりも悪くなります。
• chrome.tabs.onUpdated/onActivated、

  chrome.webNavigation 範囲がまれな URL に限定されない場合、 chrome.webRequest 範囲がまれな URL またはタイプに限定されない場合、

  chrome.runtime.onMessage/onConnect すべてのタブのコンテンツ スクリプトのメッセージ。

• 新しいイベントのために SW を起動することは、基本的に新しいタブを開くことに似ています。環境の作成には約 50 ミリ秒、SW スクリプト全体の実行にはおそらく 100 ミリ秒 (コードの量によっては 1000 ミリ秒)、ファイルの読み取りにはおそらく 1 ミリ秒 (またはデータによっては 1000 ミリ秒) かかります。保管時の状態と再構築/ハイドレート。複雑さ)。ほとんど空のスクリプトを使用した場合でも、少なくとも 50 ミリ秒かかります。これは、わずか 1 ミリ秒しかかからないイベント リスナーを呼び出すのにかなりのオーバーヘッドです。

  SW は 1 日に何百回も再起動される可能性があります。このようなイベントは、タブをクリックしてから何かを書き込むなど、自然なギャップのあるユーザー アクションに応じて生成され、その間にソフトウェアが終了し、新しいイベントが発生した場合に再起動されるためです。 CPU、ディスク、バッテリーを消費し、一般にスケーリングの応答に頻繁に認識可能な遅れが生じます。

エラーによる「永続的」Service Worker の悪用

Chrome 110 にはバグが導入されました。非同期 chrome API を呼び出すと、ワーカー スレッドがさらに 30 秒間実行されます。このバグはまだ修正されていません。

//Background.js

リーリー

オフスクリーン API を使用した「永続的」Service Worker

Kevin Augusto による寄稿。

Chrome 109 以降では、

オフスクリーン API を使用してオフスクリーン ドキュメントを作成し、そこから 30 秒以内にメッセージを送信して Service Worker を実行し続けることができます。現在、ドキュメントの有効期間は制限されていません (音声再生のみが制限されており、これは使用しません) が、これは将来変更される可能性があります。

• マニフェスト.json

  リーリー

• オフスクリーン.html

  リーリー

• オフスクリーン.js

  リーリー

• Background.js

  リーリー

接続

nativeMessaging ホストタイムの「永続的」サービス ワーカー スレッド

Chrome 105 以降では、

chrome.runtime.connectNative を渡すだけです。クラッシュまたはユーザーの操作によりホスト プロセスが終了した場合、ポートは閉じられ、ソフトウェアは通常どおり終了します。ポートの onDisconnect イベントをリッスンすることで、chrome.runtime.connectNative が再度呼び出されないようにすることができます。

WebSocket がアクティブな間、「永続的な」Service Worker スレッドを実行します

Chrome 116 以降: WebSocket メッセージを 30 秒ごとに交換して存続させます (たとえば、25 秒ごと)。

接続可能なタブが存在する間は「永続的」サービスワーカー

欠点:

開いたWebタブが必要です
コンテンツ スクリプトに対する広範なホスト権限 (例:
• または *://*/*)。これにより、ほとんどの拡張機能がウェブ ストアのキューに入れられ、遅いレビューが行われます。

警告!ポートが接続されている場合は、この回避策を使用せず、以下のポートに対して別の回避策を使用してください。

警告! sendMessage を使用する場合は、sendMessage の回避策 (下記) を実装することもできます。

• manifest.json、関連部分:

  リーリー

• バックグラウンド サービス ワーカー bg.js：

  リーリー

• 他のすべての拡張ページ (ポップアップやオプションなど):

  リーリー

sendMessage も使用する場合

Chrome 99-101 では、応答が必要ない場合でも、chrome.runtime.onMessage リスナーで sendResponse() を常に呼び出す必要があります。これはMV3のバグです。また、これは 5 分以内に行うようにしてください。それ以外の場合は、作業が完了したらすぐに sendResponse を呼び出し、chrome.tabs.sendMessage (タブへ) または chrome.runtime.sendMessage (ポップアップへ) 経由で新しいメッセージを送信します。

chrome.runtime.connect などのポートをすでに使用している場合

警告!さらに多くのポートを Service Worker に接続する場合は、5 分が経過する前 (たとえば、295 秒以内) に各ポートを再接続する必要があります。これは Chrome バージョン 104 よりも前のバージョンでは重要であり、追加の接続ポートがどれほど多くても SW が強制終了されてしまいます。 Chrome 104 以降では、このバグは修正されていますが、5 分間のライフサイクルは変わっていないため、引き続き再接続する必要があります。そのため、最も簡単な解決策は、Chrome 接続のすべてのバージョンで同じ方法で (たとえば 295 秒ごとに) 再接続することです。

• バックエンド スクリプトの例:

  リーリー

• コンテンツ スクリプトなどのクライアント スクリプトの例:

  リーリー

「常に」、専用タブ経由、タブが開いているとき

ソフトウェアを使用する代わりに、拡張ページを内部に含む新しいタブを開くと、このページが「表示される背景ページ」として機能します。つまり、ソフトウェアが行う必要があるのはこのタブを開くことだけです。アクションポップアップから開くこともできます。

リーリー

これは ManifestV2 の永続的な背景ページと同じ機能を持ちますが、a) 表示されますが、b) chrome.extension.getBackgroundPage (chrome で置き換えることができます) 経由ではアクセスできません。 .拡張子 .getViews)。

欠点:

• より多くのメモリを消費します。
• タブバーのスペースの無駄、
• ユーザーの注意をそらす、
• 複数の拡張機能がこのようにタブを開くと、デメリットが雪だるま式に増えて、本当の PITA になる可能性があります。

info/logs/charts/dashboard をページに追加することでユーザーが使いやすくすることができます。また、タブが誤って閉じられるのを防ぐために beforeunload リスナーを追加することもできます。

永続性に関する警告

永続的なサービス ワーカーなどは存在せず、これらの回避策にはワーカーが終了できるように前述した制限があるため、状態 (変数) を保存/復元する必要があります。ストレージ内の状態を維持できます (Example)。

状態/変数の管理を簡素化するためだけにワーカー スレッドを永続化しないでください。これは、状態の再構築に非常にコストがかかる場合、またはこの回答の冒頭にリストされている頻繁なイベントに巻き込まれた場合に、ワーカー スレッドの再起動によって悪化したパフォーマンスを復元するためにのみ行われます。