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 コンセプトを公開できます。
次に、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 拡張機能について話し合うこともできます。