Les extensions construites avec les APIs WebExtension sont conçues pour être compatible avec les extensions Chrome et Opera : le plus souvent possible, les extensions créées pour ces navigateurs devraient fonctionner sur Firefox avec des changements mineurs.

Cependant, Firefox ne supporte pour le moment que certaines fonctions et API de Chrome et Opera. Nous travaillons sur le support de davantage d'entre elles, mais beaucoup ne sont pas encore supportées et certaines ne le seront jamais.

APIs Javascript

Callbacks et  le chrome.* namespace

Dans Chrome, les extensions permettent d'accèder aux APIs JavaScript privilégiées à l'aide des espaces de noms dans Chrome :

chrome.browserAction.setIcon({path: "path/to/icon.png"});

Les webExtensions accèdent aux API équivalentes à l'aide de l'espace de noms du navigateur:

browser.browserAction.setIcon({path: "path/to/icon.png"});

Beaucoup d'API sont asynchrones. Dans Chrome, les API asynchrones utilisent des rappels pour renvoyer des valeurs et runtime.lastError pour communiquer les erreurs :

function logCookie(c) {
  if (chrome.extension.lastError) {
    console.error(chrome.extension.lastError);
  } else {
    console.log(c);
  }
}

chrome.cookies.set(
  {url: "https://developer.mozilla.org/"},
  logCookie
);

Les API WebExtensions équivalentes utilisent plutôt promises :

function logCookie(c) {
  console.log(c);
}

function logError(e) {
  console.error(e);
}

var setCookie = browser.cookies.set(
  {url: "https://developer.mozilla.org/"}
);
setCookie.then(logCookie, logError);

Firefox prend en charge les espaces de noms chrome et browser

En tant qu'aide de portage, la mise en œuvre de Firefox de WebExtensions prend en charge chrome, utilisé callbacks, ainsi qu'un navigateur, utilisant les promesses. Cela signifie que de nombreuses extensions Chrome fonctionneront simplement dans Firefox sans aucun changement. Cependant, cela ne fait pas partie de la norme WebExtensions et peut ne pas être pris en charge par tous les navigateurs compatibles.

Si vous écrivez votre extension pour utiliser le navigateur et les promises, nous avons également développé un polyfill qui lui permettra de fonctionner sur Chrome : https://github.com/mozilla/webextension-polyfill.

APIs partiellement prises en charge

Le support du navigateur de la page pour les API Javascript comprend des tables de compatibilité pour toutes les API qui ont un support dans Firefox. Lorsqu'il y a des réserves autour du support pour un élément API donné, ceci est indiqué dans ces tableaux avec un astérisque "*" et dans la page de référence pour l'élément API, les mises en garde sont expliquées.

Ces tables sont générées à partir des données de compatibilité stockées en tant que  fichiers JSON dans GitHub.

Le reste de cette section décrit les problèmes de compatibilité qui ne sont pas encore pris en compte dans les tableaux.

notifications

  • Pour notifications.create(), avec le type "basic", iconUrl est optionnel dans Firefox. Il est obligatoire dans Chrome.
  • Les notifications sont effacées immédiatement lorsque l'utilisateur clique dessus. Ce n'est pas le cas dans Chrome.

  • Si vous appelez notifications.create() plus d'une fois en succession rapide, Firefox peut finir par ne pas afficher de notification du tout. En attendant de faire des appels ultérieurs jusqu'à ce que, dans la fonction chrome.notifications.create(), le rappel ne soit pas suffisamment long pour éviter que cela ne se produise.

proxy

  • Cette API est complètement différente de la conception de l'API Chrome. Avec l'API de Chrome, une extension peut enregistrer un fichier PAC, mais peut également définir des règles de proxy explicites. Comme cela est également possible en utilisant les fichiers PAC étendus, cette API ne prend en charge que l'approche de fichier PAC. Étant donné que cette API est incompatible avec l'API de proxy Chrome, cette API est uniquement disponible via l'espace de noms du navigateur.

Onglets

  • Dans Firefox, les URL relatives passées dans tabs.executeScript() ou tabs.insertCSS() sont résolues par rapport à l'URL de la page actuelle. Dans Chrome, ces URL sont résolues par rapport à l'URL de base de l'extension. Pour travailler à travers le navigateur, vous pouvez spécifier le chemin comme URL absolue, en commençant par la racine de l'extension, comme ceci:

    /path/to/script.js
  • Dans Firefox, les onglets d'interrogation par URL avec tabs.query() nécessitent une permission "tabs". Dans Chrome, il est possible sans la permission "tabs" mais limitera les résultats aux onglets dont les URL correspondent aux permissions de l'hôte.

webRequest

  • Dans Firefox, les demandes ne peuvent être redirigées que si leur URL d'origine utilise le schéma http: or https:

windows

  • Dans Firefox onFocusChanged déclenchera plusieurs fois pour un changement de focus donné.

Incompatibilités diverses

URLs dans CSS

Firefox résout les URL dans les fichiers CSS injectés par rapport au fichier CSS lui-même, plutôt que dans la page dans laquelle il est injecté.

Incompatibilités supplémentaires

Firefox ne prend pas en charge l'utilisation alert(), confirm(), ou prompt() à partir des pages d'arrière-plan.

web_accessible_resources

Dans Chrome, lorsqu'une ressource est répertoriée dans web_accessible_resources, elle est accessible en tant que chrome-extension://<your-extension-id>/<path/to/resource>. L'extension ID est fixé pour une extension donnée.

Firefox l'implémente autrement, en utilisant un UUID aléatoire qui change pour chaque instance de Firefox: moz-extension://<random-UUID>/<path/to/resource>. Cette aléatoire peut vous empêcher de faire quelques choses, comme ajouter l'URL de votre extension spécifique à la politique CSP d'un autre domaine.

La propriété "clé" du manifest

Lorsque vous travaillez avec une extension décompressée, Chrome permet d'ajouter une propriété "clé" au manifest pour repérer l'ID d'extension sur différentes machines. Ceci est principalement utile lorsque vous travaillez avec les web_accessible_resources. Puisque Firefox utilise des UUID aléatoires pour les web_accessible_resources, cette propriété n'est pas prise en charge.

Les demandes de script de contenu ont lieu dans le contexte de l'extension, pas dans la page de contenu

Dans Chrome, lorsque la requête est appelée (par exemple, en utilisant fetch()) pour une URL relative comme /api du script de contenu, elle sera envoyée à https://example.com/api. Dans Firefox, vous devez fournir des URL abolues.

 

Les clés manifest.json

La page principale manifest.json comprend un tableau décrivant le support du navigateur pour les clés manifest.json. Lorsqu'il y a des mises en garde concernant le support d'une clé donnée, ceci est indiqué dans le tableau avec un astérisque "*" et dans la page de référence de la clé, les mises en garde sont expliquées.

 

Ces tables sont générées à partir des données de compatibilité stockées en tant que fichiers JSON dans GitHub.

Messagerie native

Arguments de ligne de commande

Sur Linux et Mac, Chrome passe un argument sur l'application natif, qui est l'origine de l'extension qui l'a lancée, sous la forme : chrome-extension://[extensionID]. Cela permet à l'application d'identifier l'extension.

Sur Windows, Chrome passe deux arguments: le premier est l'origine de l'extension, et le second est un handle de la fenêtre native de Chrome qui a démarré l'application.

allowed_extensions

Dans Chrome, la clé allowed_extensions dans le manifest de l'application est appelée allowed_origins à la place.

App manifest location

Chrome s'attend à trouver le manifest de l'application dans un autre endroit. Regarder l'emplacement de l'hôte de messagerie natif dans les documents Chrome.

Étiquettes et contributeurs liés au document

Étiquettes : 
 Contributeurs à cette page : wtoscer, hellosct1, Goofy, Bat41
 Dernière mise à jour par : wtoscer,