Transition vers l'espace de noms du navigateur

À partir de Chrome 148, toutes les API Chrome Extension sont disponibles dans l'espace de noms browser, en plus de l'espace de noms chrome existant. Par exemple, browser.tabs.create({}) et chrome.tabs.create({}) sont équivalents.

L'espace de noms est disponible partout où vous pouvez appeler des API d'extension, y compris les scripts de contenu, les service workers et les documents hors écran. Il pointe vers les mêmes objets API que chrome, donc chrome.tabs === browser.tabs.

L'espace de noms browser est le fruit du travail du WebExtensions Community Group (WECG), un groupe de la communauté W3C où les fournisseurs de navigateurs collaborent sur des normes d'extension partagées. L'espace de noms chrome ne disparaît pas. Les deux espaces de noms continueront de fonctionner.

Décider d'adopter ou non l'espace de noms du navigateur

Si vous utilisez webextension-polyfill, passez à la section Remarque à l'attention des utilisateurs de polyfill avant de modifier quoi que ce soit d'autre. La réponse est différente pour vous.

Si vous créez une extension, définissez minimum_chrome_version sur "148" et utilisez browser sans condition. Vous pouvez arrêter la lecture ici. Le reste de cette section est destiné aux extensions existantes qui décident de l'adopter.

Vérifier les versions de Chrome utilisées par vos utilisateurs

Si vous disposez d'une extension existante, vérifiez les versions de Chrome utilisées par vos utilisateurs avant de passer à une autre version. Chrome se met à jour automatiquement, mais certains utilisateurs désactivent les mises à jour et d'autres utilisent des appareils plus anciens qui ne peuvent pas exécuter la dernière version. Vérifiez vos propres données Analytics. Si vous n'avez pas encore configuré Analytics yet, consultez Surveiller les performances de votre extension avec Google Analytics 4 pour commencer.

Choisissez ensuite un chemin d'accès :

Adopter sans condition

Définissez minimum_chrome_version dans votre fichier manifeste et utilisez browser sans condition. Aucun garde d'exécution n'est nécessaire :

{
  "minimum_chrome_version": "148"
}

Utilisez un déploiement par étapes lorsque vous augmentez minimum_chrome_version. En cas de problème, vous pouvez annuler le déploiement de votre extension dans le Chrome Web Store.

Utiliser le garde d'exécution

Ajoutez l'extrait suivant au début du code de démarrage de votre extension avant de référencer browser ailleurs :

if (!globalThis.browser) {
  globalThis.browser = chrome;
  // Consider firing an analytics event here to measure how often
  // your users hit this fallback path.
}

Cela fait de browser un alias pour chrome dans les versions antérieures, de sorte que le reste de votre code peut utiliser browser sans condition.

Remarque à l'attention des utilisateurs de polyfill

Si votre extension utilise webextension-polyfill, elle devient une opération sans effet sur Chrome 148 et versions ultérieures. Le polyfill a ignoré l'encapsulation lorsque browser était déjà défini, en supposant que le navigateur hôte avait déjà fourni l'API.

Une tentative antérieure de distribuer l'espace de noms dans Chrome 136 a été annulée pour cette raison : avec browser nouvellement défini, le polyfill a cessé l'encapsulation, mais browser.runtime.onMessage de Chrome n'était pas encore compatible avec les écouteurs renvoyant des promesses, que le polyfill avait fournis. Les extensions reposant sur ce modèle ont été interrompues. Chrome 148 distribue l'espace de noms et les écouteurs onMessage natifs renvoyant des promesses ensemble pour éviter cet écart.

Vous pouvez supprimer la dépendance polyfill une fois que votre base d'utilisateurs est passée à Chrome 148.

Autres fonctionnalités

Réponses asynchrones dans runtime.sendMessage

Dans Chrome 148, les écouteurs runtime.onMessage peuvent renvoyer directement une Promise pour envoyer une réponse asynchrone. Cela fonctionne que vous l'appeliez à l'aide de chrome.* ou de browser.*.

Auparavant, la seule façon de répondre de manière asynchrone était de renvoyer un littéral true de l'écouteur et d'appeler sendResponse ultérieurement :

// Old pattern - requires returning true to keep the channel open
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  fetch('https://example.com')
    .then(response => sendResponse({ statusCode: response.status }));

  return true; // keeps the message channel open for the async response
});

Vous pouvez désormais renvoyer directement une Promise (ou utiliser une fonction async) :

// New pattern - return a promise or use async/await
browser.runtime.onMessage.addListener(async (message, sender) => {
  const response = await fetch('https://example.com');
  return { statusCode: response.status };
});

Le modèle return true continue de fonctionner. Il n'est donc pas nécessaire de modifier le code existant.