Chrome 拡張機能がリリースされて以来、このプラットフォームではデベロッパーはアクションを使用して、トップレベルの Chrome UI で拡張機能を直接公開できるようになりました。アクションは、ポップアップを開いたり、拡張機能の一部の機能をトリガーしたりできるアイコンボタンです。これまで Chrome では、ブラウザ アクションとページ アクションの 2 種類のアクションをサポートしていましたが、Manifest V3 ではこの機能を新しい chrome.action API に統合することでこれを改善しました。
拡張機能のアクションの簡単な履歴
chrome.action 自体は Manifest V3 の新機能ですが、基本的な機能は、拡張機能が 2010 年 1 月に安定版としてリリースされた時点まで遡ります。Chrome の拡張機能プラットフォームの最初の安定版リリースでは、ブラウザ アクションとページ アクションという 2 種類のアクションをサポートしていました。
拡張機能のデベロッパーは、ブラウザ アクションを使用して「Google Chrome のメイン ツールバーにあるアドレスバーの右側」アイコン（ソース）を表示でき、ユーザーは任意のページで拡張機能を簡単にトリガーできるようになりました。一方、ページ アクションは、「現在のページで実行できるが、すべてのページに適用されるわけではない」ことを意図したもの（出典）。
つまり、ブラウザ アクションにより、拡張機能のデベロッパーはブラウザ内の永続的な UI サーフェスを利用できますが、ページ アクションは、拡張機能が現在のページで有用な処理を行える場合にのみ表示されます。
どちらの種類のアクションもオプションであったため、拡張機能のデベロッパーは、アクションなし、ページ アクション、またはブラウザ アクション（複数のアクションの指定は許可されていません）のいずれかを提供するように選択できました。
約 6 年後、Chrome 49 で拡張機能の新しい UI パラダイムが導入されました。そこで、ユーザーが現在使用している拡張機能を理解しやすくするため、Chrome のアドレスバーの右側に、アクティブな拡張機能がすべて表示されます。ユーザーは必要に応じて、拡張機能を Chrome メニューに「オーバーフロー」させることができます。
また、各拡張機能のアイコンを表示するために、Chrome の UI での拡張機能の動作に関する 2 つの重要な変更も行われました。まず、すべての拡張機能で、ツールバーにアイコンが表示されるようになります。拡張機能にアイコンがない場合、Chrome によってアイコンが自動生成されます。第 2 に、ページ アクションはブラウザ アクションと並んでツールバーに移動し、「表示」状態と「非表示」状態を区別するアフォーダンスを提供しました。
この変更により、ページ アクション拡張機能は引き続き想定どおりに機能していましたが、ページ アクションの役割も徐々に縮小しました。UI デザインの刷新による効果の 1 つとして、ページ アクションがブラウザ アクションによって実質的に包含されていたことが挙げられます。すべての拡張機能がツールバーに表示されるため、ユーザーは拡張機能のツールバー アイコンをクリックすると拡張機能が呼び出されると予想し、Chrome 拡張機能ではブラウザ アクションがますます重要になっています。
Manifest V3 の変更
Chrome の UI と拡張機能は、2016 年の拡張機能 UI の再設計後も進化を続けましたが、ブラウザ アクションとページ アクションはほぼ変更されていません。つまり、少なくとも Manifest V3 で拡張機能プラットフォームをモダナイズする方法を計画し始めるまでは、
拡張機能チームは、ブラウザ アクションとページ アクションが無意味に区別されるようになったことは明らかでした。さらに悪いことに、動作が微妙に異なるため、デベロッパーがどれを使用するかを判断するのが困難でした。Google では、ブラウザのアクションとページ アクションを 1 つの「アクション」にまとめることで、これらの問題に対処できると考えました。
Action API を開始します。chrome.action は chrome.browserAction とほぼ同じですが、注意すべき違いがいくつかあります。
まず、chrome.action に getUserSettings() という名前の新しいメソッドが導入されています。このメソッドにより、拡張機能のデベロッパーは、ユーザーが拡張機能のアクションをツールバーに固定しているかどうかを確認できます。
let userSettings = await chrome.action.getUserSettings();
console.log(`Is the action pinned? ${userSettings.isOnToolbar ? 'Yes' : 'No'}.`);
この機能の「getUserSettings」は「isPinned」などと比べるとちょっと変わった名前のように思えるかもしれませんが、Chrome の操作履歴から、ブラウザの UI は拡張 API よりも速く変更されていることがわかっています。そのため、この API の目的は、将来的な API のチャーンを最小限に抑えるために、アクション関連のユーザー設定を汎用インターフェース上で公開することです。また、他のブラウザ ベンダーも、このメソッドから返される UserSettings オブジェクトでブラウザ固有の UI のコンセプトを公開できます。
次に、Declarative Content API を使用して、拡張機能のアクションのアイコンと有効/無効状態を制御できます。このようにすることで、拡張機能が、ユーザーがアクセスしたページのコンテンツや URL にアクセスしなくても、ユーザーの閲覧行動に対応できるようになるため、これは重要なことです。たとえば、ユーザーが example.com のページにアクセスしたときに拡張機能がアクションを有効にする方法を見てみましょう。
// Manifest V3
chrome.runtime.onInstalled.addListener(() => {
chrome.declarativeContent.onPageChanged.removeRules(undefined, () => {
chrome.declarativeContent.onPageChanged.addRules([
{
conditions: [
new chrome.declarativeContent.PageStateMatcher({
pageUrl: {hostSuffix: '.example.com'},
})
],
actions: [new chrome.declarativeContent.ShowAction()]
}
]);
});
});
上記のコードは、拡張機能がページ アクションを処理する場合とほぼ同じです。唯一の違いは、Manifest V3 では Manifest V2 の declarativeContent.ShowPageAction ではなく declarativeContent.ShowAction を使用したことです。
最後に、コンテンツ ブロッカーは declarativeNetRequest API の setExtensionActionOptions）メソッドを使用して、特定のタブに対して拡張機能によってブロックされたリクエスト数を表示できます。機密の可能性がある閲覧メタデータを拡張機能に公開することなく、コンテンツ ブロッカーがエンドユーザーに最新情報を提供できるため、この機能は重要です。
まとめ
Chrome 拡張機能プラットフォームのモダナイゼーションは、Manifest V3 を導入する大きな動機の一つでした。多くの場合、新しいテクノロジーへの切り替えだけでなく、API サーフェスの簡素化も意味しました。それが私たちの目標でした。
今回の投稿が、Manifest V3 プラットフォームの今回の問題点について少しでも理解するためのお役に立てば幸いです。Chrome チームによる今後のブラウザ拡張機能の取り組みについて詳しくは、デベロッパー向けドキュメントのプラットフォームのビジョンと Manifest V3 の概要のページをご覧ください。また、chromium-extensions Google グループで、他のデベロッパーと Chrome 拡張機能について話し合うこともできます。