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 の変更
2016 年の拡張機能 UI の再設計以降、Chrome の UI と拡張機能は進化し続けましたが、ブラウザ アクションとページ アクションはほとんど変更されませんでした。少なくとも、Manifest V3 で拡張機能プラットフォームをモダナイズする方法を計画し始めるまではそうでした。
ブラウザ アクションとページ アクションの区別は、意味のない区別になりつつあることが拡張機能チームには明らかでした。さらに、動作の微妙な違いにより、デベロッパーがどちらを使用するかを判断するのが困難でした。ブラウザ アクションとページ アクションを 1 つの「アクション」に統合することで、これらの問題に対処できることがわかりました。
Action API を導入します。chrome.action は chrome.browserAction に最も近い API ですが、いくつかの重要な違いがあります。
まず、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 コンセプトを公開できます。
2 つ目は、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 V2 では declarativeContent.ShowPageAction の代わりに declarativeContent.ShowAction を使用していることです。
最後に、コンテンツ ブロッカーは declarativeNetRequest API の setExtensionActionOptions メソッドを使用して、特定のタブで拡張機能によってブロックされたリクエストの数を表示できます。この機能は、コンテンツ ブロッカーが機密性の高いブラウジング メタデータを拡張機能に公開することなく、エンドユーザーに情報を提供できるようにするため重要です。
まとめ
Chrome 拡張機能プラットフォームのモダナイゼーションは、Manifest V3 の主要な動機の 1 つでした。多くの場合、これは新しいテクノロジーに切り替えることを意味しましたが、API サーフェスの簡素化も意味しました。これが今回の目標でした。
この投稿が、Manifest V3 プラットフォームのこの部分について理解を深めるのに役立つことを願っています。Chrome チームがブラウザ拡張機能の将来に取り組んでいる方法について詳しくは、デベロッパー向けドキュメントのプラットフォームのビジョンと Manifest V3 の概要をご覧ください。chromium-extensions Google グループで、他のデベロッパーと Chrome 拡張機能について話し合うこともできます。