Depuis le lancement des extensions Chrome, la plate-forme a permis aux développeurs d'exposer les fonctionnalités d'extension directement dans l'interface utilisateur Chrome de premier niveau à l'aide d'actions. Une action est une icône qui peut ouvrir un pop-up ou déclencher certaines fonctionnalités de l'extension. À l'origine, Chrome prenait en charge deux types d'actions : les actions de navigateur et les actions de page. Manifest V3 a résolu ce problème en consolidant leurs fonctionnalités dans une nouvelle API chrome.action.
Un bref historique des actions d'extension
Bien que chrome.action lui-même soit nouveau dans Manifest V3, la fonctionnalité de base qu'il fournit remonte à l'arrivée en version stable des extensions en janvier 2010. La première version stable de la plate-forme d'extensions de Chrome permettait d'effectuer deux types d'actions: les actions de navigateur et les actions de page.
Les actions du navigateur permettaient aux développeurs d'extensions d'afficher une icône "dans la barre d'outils principale de Google Chrome, à droite de la barre d'adresse" (source) et offraient aux utilisateurs un moyen simple de déclencher les fonctionnalités d'extension sur n'importe quelle page. Les actions sur une page, en revanche, étaient destinées à "représenter des actions qui peuvent être effectuées sur la page actuelle, mais qui ne s'appliquent pas à toutes les pages" (source).
En d'autres termes, les actions du navigateur offraient aux développeurs d'extensions une surface d'interface utilisateur persistante dans le navigateur, tandis que les actions sur les pages ne s'affichaient que lorsque l'extension pouvait effectuer une action utile sur la page actuelle.
Les deux types d'actions étant facultatifs, un développeur d'extensions pouvait choisir de ne fournir aucune action, une action sur la page ou une action de navigateur (la spécification de plusieurs actions n'est pas autorisée).
Environ six ans plus tard, Chrome 49 a introduit un nouveau paradigme d'interface utilisateur pour les extensions. Pour aider les utilisateurs à comprendre les extensions dont ils disposaient, Chrome a commencé à afficher toutes les extensions actives à droite de l'omnibox. Les utilisateurs pouvaient "déborder" des extensions dans le menu Chrome s'ils le souhaitaient.
Afin d'afficher une icône pour chaque extension, cette mise à jour a également apporté deux modifications importantes au comportement des extensions dans l'interface utilisateur de Chrome. Tout d'abord, toutes les extensions ont commencé à afficher des icônes dans la barre d'outils. Si l'extension ne comportait pas d'icône, Chrome en génère une automatiquement. Ensuite, les actions de page ont été déplacées dans la barre d'outils parallèlement aux actions du navigateur et ont reçu une affordance pour les différencier des états "Afficher" et "Masquer".
Ce changement a permis aux extensions d'action sur la page de continuer à fonctionner comme prévu, mais a également diminué le rôle de ces actions au fil du temps. L'un des effets de la refonte de l'interface utilisateur était que les actions de page étaient en réalité submergées par les actions du navigateur. Comme toutes les extensions apparaissaient dans la barre d'outils, les utilisateurs s'attendaient à ce qu'un clic sur l'icône de la barre d'outils d'une extension l'appelait. Les actions du navigateur devenaient alors une interaction de plus en plus importante pour les extensions Chrome.
Modifications de Manifest V3
L'UI et les extensions de Chrome ont continué à évoluer dans les années qui ont suivi la refonte de l'interface utilisateur des extensions en 2016, mais les actions du navigateur et des pages sont restées globalement inchangées. C'est-à-dire, au moins jusqu'à ce que nous ayons commencé à planifier la modernisation de la plate-forme des extensions avec Manifest V3.
Pour l'équipe des extensions, il est apparu clairement que les actions du navigateur et les actions sur les pages étaient de plus en plus une distinction incompréhensible. Pire encore, leurs légères différences de comportement empêchaient les développeurs de déterminer lequel utiliser. Nous avons réalisé que nous pouvions résoudre ces problèmes en combinant l'action du navigateur et l'action sur la page en une seule "action".
Accédez à l'API Action. chrome.action est le plus semblable à chrome.browserAction, mais présente quelques différences notables.
Tout d'abord, chrome.action introduit une nouvelle méthode nommée getUserSettings(). Cette méthode permet aux développeurs d'extensions de vérifier si l'utilisateur a épinglé l'action de leur extension dans la barre d'outils.
let userSettings = await chrome.action.getUserSettings();
console.log(`Is the action pinned? ${userSettings.isOnToolbar ? 'Yes' : 'No'}.`);
"getUserSettings" peut sembler un nom inhabituel pour cette fonctionnalité, par exemple "isPinned", mais l'historique des actions dans Chrome montre que l'interface utilisateur du navigateur change plus rapidement que les API d'extension. Notre objectif avec cette API est donc d'afficher les préférences utilisateur liées aux actions sur les interfaces génériques afin de réduire la perte d'API à l'avenir. Elle permet également aux autres fournisseurs de navigateurs d'exposer des concepts d'interface utilisateur spécifiques aux navigateurs dans l'objet UserSettings renvoyé par cette méthode.
Ensuite, l'icône et l'état d'activation/de désactivation de l'action d'une extension peuvent être contrôlés à l'aide de déclarative Content API. Ce point est important, car il permet aux extensions de réagir au comportement de navigation de l'utilisateur sans accéder au contenu ni même aux URL des pages qu'il consulte. Voyons par exemple comment une extension peut activer son action lorsque l'utilisateur visite des pages sur 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()]
}
]);
});
});
Le code ci-dessus est presque identique à ce qu'une extension ferait avec une action sur une page. La seule différence est que dans Manifest V3, nous avons utilisé declarativeContent.ShowAction au lieu de declarativeContent.ShowPageAction dans Manifest V2.
Enfin, les bloqueurs de contenu peuvent utiliser la méthode setExtensionActionOptions de l'API déclarativeNetRequest pour afficher le nombre de requêtes bloquées par l'extension pour un onglet donné. Cette fonctionnalité est importante, car elle permet aux bloqueurs de contenu d'informer les utilisateurs finaux sans exposer à l'extension des métadonnées de navigation potentiellement sensibles.
Conclusion
La modernisation de la plate-forme d'extensions Chrome était l'une des principales motivations de Manifest V3. Dans de nombreux cas, cela impliquait de passer à de nouvelles technologies, mais aussi de simplifier la surface de notre API. C'est notre objectif ici.
J'espère que cet article vous a permis de mettre en lumière cet aspect particulier de la plate-forme Manifest V3. Pour en savoir plus sur la façon dont l'équipe Chrome envisage l'avenir des extensions de navigateur, consultez les pages Vision de la plate-forme et Présentation de Manifest V3 dans notre documentation destinée aux développeurs. Vous pouvez également discuter des extensions Chrome avec d'autres développeurs dans le groupe Google chromium-extensions.