Manifest V3 に移行する際の既知の問題

このページでは、マニフェスト V3 への移行中に解決されたプラットフォームのギャップと、移行に関するよくある質問への回答について説明します。

プラットフォームのギャップを解消

一般的な移行の妨げに対処するために、次の機能が追加されました。

  1. chrome.fileBrowserHandler の代替として ChromeOS でのファイル処理のサポート（Chrome 120）。
  2. ユーザー スクリプトのサポート: 新しい userScripts API（Chrome 120）を使用して、任意のコードを含むコンテンツ スクリプトを登録できるようになりました。
  3. 5 分以上かかる特定のオペレーションに対する追加の強力な Service Worker キープアライブ。
    • Chrome 116 で permissions.request()、desktopCapture.chooseDesktopMedia()、identity.launchWebAuthFlow()、management.uninstall() に追加されました。
    • chrome.debugger 向けに Chrome 118 で追加されました。
  4. Declarative Net Request（DNR）の静的ルールセットと有効なルールセットの数を増やします。有効な静的ルールセットが 10 から 50 に、静的ルールセットの合計が 50 から 100 に増加しました（Chrome 120）。
  5. オフスクリーン ドキュメントの機能を拡張し、オフスクリーン ドキュメントを使用する理由をさらにサポートします。Chrome 116 で GEOLOCATION を追加しました。
  6. chrome.tabCapture API のサポートの改善（Chrome 116）:
    • Service Worker からの getMediaStreamId() の呼び出しをサポートします。
    • オフスクリーン ドキュメントでストリーム ID から MediaStream を取得することをサポートします。
  7. アクティブな WebSocket 接続がある間、Service Worker の有効期間を延長（Chrome 116）。

Manifest V3 に関するよくある質問

Q: 永続的な Service Worker をサポートする予定はありますか？
A: バックグラウンド スクリプトからサービス ワーカーに移行する主な理由の一つは、サービス ワーカーの一時的な性質から得られる、メモリ効率の高いイベント駆動型プログラミング モデルです。そのため、永続的なサービス ワーカーをサポートする予定はありません。ただし、拡張機能デベロッパーの特定のニーズに対応するため、サービス ワーカーの改善を継続して行っています。具体的には、次のとおりです。

  • 拡張機能のすべてのイベントと API 呼び出しは、Service Worker のライフタイムを延長します。
  • ネイティブ メッセージングなどのユースケースが選択されている場合、拡張機能のサービス ワーカーは 5 分以上存続します。

Q: サービス ワーカーで DOM にアクセスする方法はありますか？
A: ウェブ プラットフォームが採用している、ウェブ ワーカー（サービス ワーカーを含む）に DOM アクセスを含めないというアプローチに準拠しています。Service Worker からのバックグラウンド DOM アクセスを必要とするユースケースをサポートするため、バックグラウンド作業を短期間の Offscreen ドキュメントに委任する可能性を導入しました。これにより、完全な DOM アクセスが可能になります。

Q: Manifest V3 でリモートコードをサポートする方法はありますか？
A: Chrome 拡張機能のセキュリティを強化するため、Chrome 拡張機能でのリモートでホストされている任意のコードの実行は引き続き禁止されます。ただし、これはあらゆる種類の動的コード実行を禁止するという意味ではありません。Chrome 拡張機能でのコードの動的実行には、引き続きさまざまなオプションがサポートされています。

Q: Manifest V2 拡張機能は webRequestBlocking に依存していますが、Manifest V3 ではサポートされていません。Manifest V3 で同じ機能を提供するにはどうすればよいですか？
A: ほとんどのリクエスト ブロックのユースケースは、新しい declarativeNetRequest API で解決できると考えています。この API には、プロセス間通信のパフォーマンス オーバーヘッドを回避し、リクエストごとにコードを実行し、リクエスト時にアクティブな拡張機能プロセスを必要としないというメリットもあります。ただし、複雑な企業（または教育機関）のユースケースでは、動的リクエスト ブロックは引き続きサポートされます。

他に何かご不明な点はございますか？ご意見をお寄せください。