Modules

Comparaison avec les extensions XUL/XPCOM

Cet article dresse une comparaison technique entre la technologie WebExtensions et les extensions « classiques » développées à l'aide de XUL et XPCOM. Il est destiné à aider les personnes qui maintiennent un add-on réalisé avec ces technologies afin de le porter vers les API WebExtensions.

Cet article couvre à la fois les extensions de surcouche et les extensions bootstrappées mais pas les extensions développées avec le SDK. Pour ces extensions réalisées avec le SDK, se référer à Comparaison avec les add-ons SDK.

À un niveau basique, les extensions XUL/XPCOM sont similaires aux extensions développées avec WebExtensions. Toutes deux incluent :

  • Les fichiers de manifeste qui définissent des métadonnées pour l'extension et décrivent certains aspects de son comportement.
  • Du code JavaScript qui accède à un ensemble d'API JavaScript privilégiées et qui reste chargé tant que l'extension est activée.
  • La possibilité d'ajouter des éléments d'interface utilisateur spécifiques, tels que des boutons, au navigateur.

Cependant, au-delà de cela, les systèmes sont très différents, notamment :

  • Par rapport aux extensions XUL/XPCOM, les WebExtensions fournissent des options beaucoup plus limitées pour l'interface utilisateur de l'extension et un ensemble beaucoup plus restreint d'API JavaScript privilégiées.
  • WebExtensions ne peut accéder au contenu Web qu'en injectant des scripts distincts dans des pages Web et en les communiquant à l'aide d'une API de messagerie (ceci est également vrai pour les extensions XUL/XPCOM fonctionnant avec le mode multiprocessus de Firefox).

Le manifeste

Les extensions XUL/XPCOM possèdent deux manifestes :

  • Le fichier install.rdf contient des métadonnées sur l'extension telles que son nom, ses icônes, etc.
  • Le fichier chrome.manifest qui indique à Firefox où trouver les composants de l'extension, y compris les overlays XUL pour l'interface de l'extension, les scripts pour son comportement et les fichiers contenant des chaines localisées.

WebExtensions possède un seul manifeste appelé manifest.json. Celui-ci est utilisé pour indiquer le nom de l'extension, la description, les icônes, etc. Il permet aussi d'indiquer les boutons ajoutés à Firefox et pour répertorier les scripts dont il a besoin pour son exécution. Pour obtenir un aperçu des composants d'une extension développée à l'aide des API WebExtensions, ainsi que la manière dont elles sont spécifiées dans le fichier manifest.json, voir l'article Anatomie d'une extension.

En savoir plus

Interface utilisateur

Les extensions XUL/XPCOM peuvent créer leur interface utilisateur en manipulant directement le XUL utilisé pour spécifier l'interface utilisateur du navigateur. Elles le font en utilisant des superpositions ou avec du code JavaScript (pour les extensions bootstrapées/sans redémarrage) qui modifie le document XUL. Elles peuvent ajouter des éléments à l'interface utilisateur du navigateur et aussi modifier ou supprimer des éléments existants. De plus, elles peuvent utiliser des API telles que CustomizableUI.jsm pour créer leur interface utilisateur.

Les extensions construites avec les API WebExtensions ne possèdent pas ce type d'accès direct. À la place, une combinaison de clés contenues dans le fichier manifest.json et d'API JavaScript leur permet d'ajouter un ensemble limité de composants graphiques au navigateur. Les composants disponibles sont : 

Nom Description Utilisation indiquée par
Action du navigateur Bouton dans la barre d'outils du navigateur, avec un panneau contextuel facultatif

La clé du manifeste browser_action 

L'API browserAction

Action de la page Bouton dans la barre d'URL, avec un panneau contextuel facultatif.

La clé du manifeste page_action

L'API pageAction

Commandes Raccourcis clavier

La clé du manifeste commands

L'API commands

Menu contextuel Ajoute des éléments et des sous-menus au menu contextuel du navigateur L'API contextMenus

API privilégiées

Les extensions XUL/XPCOM ainsi que celles créées avec les API WebExtensions peuvent contenir des scripts qui restent chargés tant que l'extension elle-même est activée et qui ont accès à un ensemble d'API privilégiées. Cependant, les extensions XUL/XPCOM accèdent à une gamme beaucoup plus large d'API.

Les scripts empaquetés avec les extensions XUL/XPCOM ont accès à l'ensemble complet des API XPCOM et des  modules de code JavaScript via l'objet Components. Ils ont également un accès direct aux éléments internes du navigateur à travers des variables globales telles que gBrowser.

Les scripts WebExtensions équivalents sont appelés scripts d'arrière-plan et ont accès à un ensemble beaucoup plus restreint d'API JavaScript de haut niveau. Pour voir toutes les API privilégiées disponibles pour les scripts d'arrière-plan, consultez la page d'aperçu des API. Les scripts d'arrière-plan disposent également d'un objet window global, avec tous les objets DOM disponibles dans une page web classique.

Il y a bien plus d'API disponibles pour les extensions XUL/XPCOM que d'API disponibles pour les WebExtensions. Pour de nombreuses API XUL/XPCOM, il n'existe pas de substitut WebExtensions. Le tableau ci-dessous répertorie l'ensemble des API populaires du module Services.jsm et décrit l'API WebExtensions équivalente si elle existe.

Vous verrez que de nombreuses API n'ont pas encore d'équivalent WebExtensions. Cependant, nous avons l'intention d'étendre les API WebExtensions pour répondre aux besoins des développeurs de modules complémentaires. Aussi, si vous avez des idées, nous aimerions les entendre. Vous pouvez nous joindre sur la liste de diffusion dev-addons ou  #webextensions sur IRC.

Services.jsm API Équivalent WebExtensions
nsIAndroidBridge Aucun
nsIXULAppInfo
nsIXULRuntime
Aucun
nsIAppShellService Aucun
nsIBlocklistService Aucun
nsICacheService Aucun
nsICacheStorageService Aucun
nsIClipboard Partiel: voir l'API  clipboard, et  Interacting with the clipboard.
nsIConsoleService window.console
nsIContentPrefService Aucun
nsICookieManager2 cookies
nsIMessageSender Content scripts
CrashManager.jsm Aucun
nsIDirectoryService
nsIProperties
Aucun
nsIDOMStorageManager Aucun
nsIDOMRequestService Aucun
nsIDownloadManager downloads
nsIDroppedLinkHandler Aucun
nsIEventListenerService Aucun
nsIEffectiveTLDService Aucun
nsIFocusManager Aucun
nsIIOService
nsIIOService2
Aucun
nsILocaleService i18n
nsILoginManager Aucun
nsIWinMetroUtils Aucun
nsIMessageBroadcaster
nsIFrameScriptLoader
Scripts de contenu
nsIObserverService Aucun
nsIPermissionManager Aucun
nsIMessageBroadcaster
nsIProcessScriptLoader
Scripts de contenu
nsIPrefBranch
nsIPrefBranch2
nsIPrefService
Voir Paramètres ci-après.
nsIPromptService Aucun
mozIJSSubScriptLoader Aucun
nsIScriptSecurityManager Aucun
nsIBrowserSearchService Aucun
nsIAppStartup Aucun
mozIStorageService storage
nsIStringBundleService i18n
nsIPropertyBag2 Aucun
nsITelemetry Aucun
nsIThreadManager Aucun
nsIURIFixup Aucun
nsIURLFormatter Aucun
nsIVersionComparator Aucun
nsIWindowMediator Aucun
nsIWindowWatcher Aucun

En savoir plus

Intéragir avec le contenu web

Historiquement, les extensions XUL/XPCOM ont pu accéder directement au contenu web. Par exemple, elles peuvent directement accéder et modifier la page DOM en utilisant gBrowser :

gBrowser.contentWindow.document.querySelector("h1").innerHTML = "a kadok";

Cependant, cela n'est possible que dans un seul processus Firefox. En mode multiprocessus, le contenu web et le code d'extension s'exécutent dans différents processus et cet accès direct n'est plus possible. Les extensions qui s'appuient dessus ne fonctionnent plus.

Les extensions XUL/XPCOM peuvent toujours interagir avec le contenu web en mode multiprocessus en refactorant le code qui accède au contenu Web dans les scripts séparés appelés scripts de trame, et en utilisant le gestionnaire de messages pour communiquer avec les scripts. Toutefois, cette modification peut s'avérer complexe et impliquer des changements profonds au code de l'extension.

Par défaut, les WebExtensions sont compatibles avec le mode multiprocessus : le code qui interagit avec le contenu Web est factorisé en scripts distincts appelés scripts de conenu, qui peuvent communiquer avec le reste de l'extension grâce à une API de messagerie.

En savoir plus

Localisation

Dans une extension XUL/XPCOM, la localisation est gérée grâce à des fichiers DTD ou properties pour chaque langue prise en charge et en y faisant référence dans le fichier chrome.manifest via des instructions locales. On peut ensuite inclure des chaînes localisées dans les éléments de l'interface utilisateur ou dans le code.

L'approche générale avec WebExtensions est similaire, mais les détails diffèrent. Avec WebExtensions, les chaînes localisées sont fournies via un ensemble de fichiers JSON (un fichier par locale). La récupération des chaînes localisées dans l'extension passe par l'API  i18n.

WebExtensions ne prend pas nativement en charge la localisation des chaînes utilisées dans les documents HTML. Il faut donc le faire soi-même grâce à JavaScript en récupérant les chaînes localisées et en remplaçant dynamiquement le contenu HTML.

En savoir plus

Paramètres

Les extensions XUL/XPCOM stockent généralement les paramètres en utilisant le service de préférences XPCOM ou le système d'options inline.

Avec WebExtensions, on écrit un fichier HTML qui présente l'interface utilisateur des paramètres. Ce fichier peut inclure un script pour conserver les paramètres de l'extension. Le script accède à toutes les API WebExtensions et on utilisera généralement l'API storage pour conserver les paramètres.

L'URL du fichier HTML est ensuite indiquée dans la clé options_ui du fichier manifest.json. Votre page de paramètres apparaît ensuite dans l'entrée de l'extension dans le Gestionnaire de modules complémentaires. La page d'options peut également être ouverte via le code en utilisant un appel à l'API browser.runtime.openOptionsPage.

On notera WebExtensions ne donne pas accès à l'API Preferences. On ne peut donc pas obtenir ou définir directement les préférences du navigateur.
Certaines préférences spécifiques au navigateur peuvent toutefois être contrôlées via l'API browser.browserSettings ou browser.privacy.

En savoir plus

Étiquettes et contributeurs liés au document

Étiquettes : 
Contributeurs à cette page : SphinxKnight, LaurentBarbareau, hellosct1
Dernière mise à jour par : SphinxKnight,