先日、Manifest V2 のサポート終了スケジュールの変更についてお知らせしましたが、Google は引き続き Manifest V3 の改善に尽力していますが、Google 側で行うべき作業がまだ多くあることを認識しています。
- サポート終了の新しいスケジュールを発表する前に、優先すべきプラットフォームのギャップに対処し、このページに記載されている重大なバグをクローズしました。
- スケジュールの発表から Manifest V2 のサポート終了に向けた保留中のテストまでの間に、少なくとも 6 か月はデベロッパーが時間をかけて構築できるようにしています。
プラットフォームのギャップを埋める
Google は、新しい Manifest V2 のサポート終了スケジュールを発表する前に、以下のギャップを解消するよう努めています。
問題は、パートナー、バグレポート、デベロッパーからのフィードバックに基づいて収集されました。Google は、拡張機能プラットフォームの安定性と全体的なパフォーマンスを向上させるため、継続的な取り組みを続けています。
現在、重大なプラットフォーム ギャップと見なされる未解決の問題はありません。
最近、以下の問題が解決されています。
chrome.fileBrowserHandler
[Chrome 120] に代わるものとして、ChromeOS でのファイル処理をサポートします。- ユーザー スク��プトのサポート: 新しい userScripts API で、任意のコードを含むコンテンツ スクリプトを登録できるようになりました(Chrome 120)。
- 5 分を超える特定のオペレーションのための追加の強力な Service Worker キープアライブ。
- Chrome 116 で
permissions.request()
、desktopCapture.chooseDesktopMedia()
、identity.launchWebAuthFlow()
、management.uninstall()
に追加されました。 chrome.debugger
の Chrome 118 で追加
- Chrome 116 で
- 宣言型ネット リクエスト(DNR)の静的なルールセットと有効なルールセットの数を増やす。有効な静的ルールセットを 10 から 50 に、合計静的ルールセットを 50 から 100 に増やしました [Chrome 120]。
- 画面外ドキュメント機能を拡張して、画面外ドキュメントを使用するさまざまな理由をサポートします。Chrome 116 で
GEOLOCATION
を追加しました。 chrome.tabCapture
API のサポートの改善 [Chrome 116]:- Service Worker からの
getMediaStreamId()
の呼び出しがサポートされるようになりました。 - 画面外ドキュメントのストリーム ID から
MediaStream
を取得できるようになりました。
- Service Worker からの
- アクティブな
WebSocket
接続がある場合に Service Worker の寿命を延長できるようになりました(Chrome 116)。
Manifest V3 に関するよくある質問
Q: 永続的な Service Worker をサポートする予定はありますか?
A: バックグラウンド スクリプトから Service Worker に移行する主な理由の一つは、Service Worker のエフェメラルであるという特性から、メモリ効率に優れたイベント ドリブン プログラミング モデルです。そのため、永続的な Service Worker をサポートする予定はありません。ただし、拡張機能デベロッパーの特定のニーズに対応するために、Google は Service Worker に多くの改善を続けています。具体的には、次のとおりです。
- すべての拡張機能イベントと API 呼び出しで、Service Worker の存続期間が延長されます。
- ネイティブ メッセージングなどの特定のユースケースでは、拡張機能の Service Worker が 5 分以上存続します。
Q: Service Worker で DOM にアクセスする方法はありますか?
回答: Google は、ウェブ ワーカー(Service Worker を含む)に DOM アクセスを含めないというウェブ プラットフォームで採用されているアプローチに従っています。Service Worker がバックグラウンドで DOM にアクセスする必要がある��ースケースに対応するために、バックグラウンド処理を有効期間が短いオフスクリーン ドキュメント(���全な DOM ���クセス)に������できる機能を導入しました。
Q: Manifest V3 でリモートコードをサポートする方法はありますか?
A: Chrome 拡張機能の安全性を高めるため、Chrome 拡張機能でリモートでホストされている任意のコードの実行は今後も禁止されます。ただし、すべての種類の動的コード実行が禁止されるわけではありません。Chrome 拡張機能では、コードを動的に実行するためのさまざまなオプションを引き続きサポートしています。
- DevTools 拡張機能での
eval()
のサポート - ユーザー スクリプトのサポート。
- サンドボックス化された iframe でリモートでホストされるコードを実行する
- 実行時に拡張機能パッケージ内で解釈できる、リモートでホストされる構成ファイル。ただし、実行パスは事前に決定する必要があります。
Q: Manifest V2 拡張機能が Manifest V3 でサポートされていない webRequestBlocking を利用しています。Manifest V3 で同じ機能を引き続き使用するにはどうすればよいですか?
A: ほとんどのリクエスト ブロックのユースケースは新しい declarativeNetRequest
API で解決できると確信しています。この API には、プロセス間通信のパフォーマンス オーバーヘッドを回避できる、リクエストごとにコードを実行する、リクエスト時にアクティブな拡張プロセスが必要になるという利点もあります。ただし、企業(または教育機関)向けの複雑なユースケースでは、動的なリクエストのブロックも引き続きサポートされます。
その他の情報お知らせください。