Modules

Comparaison avec le SDK Add-on

Cet article est une comparaison technique du SDK des Add-ons et de la technologie WebExtensions. Il est destiné à aider les personnes qui ont un add-on dans le SDK, et qui envisagent de l'utiliser avec les APIs WebExtensions.

Si vous prévoyez d'ajouter une surcouche à une extension ou une extension bootstrap, consultez la page de  comparaison des extensions XUL/XPCOM.

La structure de base et les concepts du SDK des Add-on sont partagés par les WebExtensions. Les deux technologies comprennent:

Au-delà de ces grandes similitudes, il existe de nombreuses différences dans les détails, qui sont résumées dans les sections suivantes.

Les fichiers manifest

Dans les deux technologies, vous disposez d'un fichier manifest JSON dans le répertoire racune de l'extension. Dans le SDK, cela s'appelle "package.json", alors que dans les WebExtensions on l'appelle "manifest.json". Les deux fichiers contiennet des métadonnées de base telles que le nom, la description et les icônes de l'extension.

Cependant, "manifest.json" comprend de nombreuses clés qui définissent des parties des capacités et du comportement de l'extension, qui dans le SDK sont plus souvent définies dans le code. Par exemple :

Fonctionnalité Add-on SDK WebExtensions
Scripts de contenu correspondant aux modèles d'URL API page-mod Clé content_scripts
Boutons de la barre d'outils API ui/button/action Clé browser_action
Accéder aux API privilégiées Fonction require() Clé permissions

Cela rend les extensions de développement avec les API WebExtensions plus déclaratives et moins programmables par rapport aux modules SDK des add-ons.

Avec le SDK, vous utiliserez généralement jpm init pour créer un nouveau package.json. La technologie WebExtensions n'a pas d'équivalent de jpm init, dont vous allez probablement écrire le manifest à partir de zéro ou copier et adapter un fichier existant.

Scripts persitants

Les deux technologies ont la notion de scripts persistants qui restent chargés pour la durée de vie de l'extension, ont accès à des API privilégiées et peuvent communiquer avec d'autres parties de l'extension telles que les scripts de contenu.

Dans le SDK, ce script est par défaut appelé "index.js", et il charger autres scripts à l'aide du chargeur de module.

Avec les WebExtensions, ces scripts sont appelés "scripts de fond". Vous pouvez définir un ensemble de scripts à l'aide de la clé de manifeste d'arrière plan, et tous seront chargés dans le même document, qui est une page HTML vierge cachée et générée automatiquement. Vous pouvez également définir votre propre document personnalisé à l'aide de la clé d'arrière plan.

Une différence importante est que les scripts d'arrière-plan obtiennent une  fenêtre globale, avec tous les objets DOM que vous attendez d'être présents dans une fenêtre. Cela rend l'écriture des extensions comme l'écriture de pages Web, avec un accès direct à toutes les API Web normales comme XMLHttpRequest ou IndexedDB.

Notez également que par défaut, les extensions ont une politique de sécurité de contenu qui leur est appliquée. Vous pouvez spécifier votre propre politique, mais la politique par défaut, entre autres, interdit les pratiques potentiellement dangereuses telles que l'utilisation d'eval().

En apprendre plus

Scripts de contenus

A la fois dans l'extension de SDK et dans les WebExtensions, les scripts persistants ne peuvent pas accéder directement au contenu des pages Web. Au lieu de cela, les extensions peuvent être attaché aux scripts de contenu vers les pages Web. Ces scripts:

  • Obtenez un accès direct au contenu Web
  • N'ont pas accès aux API privilégiées
  • Peuvent communiquer avec les scripts persistants à l'aide d'une API de messagerie.

Dans les deux technologies, il existe deux façons d'associer des scripts: vous pouvez joindre automatiquement un ensemble de scripts de pages dont l'URL correspond à un modèle donné, ou vous pouvez associer un script par programme à la page hébergée par un onglet donné. La façon de le faire est différente dans chaque technologie, cependant:

Operation Add-on SDK WebExtensions
Attaché des scripts de pages correspond au modèle d'URL page-mod API content_scripts Clé
Attaché des scripts de pages hébergées par un onglet tab.attach() tabs.executeScript()

Les modèles de correspondance utilisés pour les URLs sont différentes :

Dans les deux technologies, vous pouvez passer des options pour contrôler lorsque le script s'exécute et s'il sera attaché aux sous-trames. Les  WebExtensions n'inclut pas un équivalent de contentScriptOptions, cependant, afin de transmettre les options de configuration à un script de contenu dans une extension, vous devrez les envoyer dans un message ou les stockers dans storage.local.

Dans les deux technologies, les scripts de contenu peuvent communiquer avec des scripts persistants à l'aide d'une API de messagerie asynchrone:

Operation Add-on SDK WebExtensions
Envoie de  message port.emit() runtime.sendMessage() / tabs.sendMessage()
Réception de  message port.on() runtime.onMessage

Dans les deux cas, les scripts de contenus peuvent communiquer avec les scripts chargés par la page à l'aide de window.postMessage et window.addEventListener.

Dans les deux technologies, accédez à la page dans laquelle ils sont injectés, mais obtenez "une vue claire du DOM", ce qui signifie qu'ils ne comprennent pas les modifications apportées au DOM par les scripts chargés par la page.

Dans le SDK, les scripts de contenu peuvent partager des objets avec des scripts de page, en utilisant les techniques comme unsafeWindow et createObjectIn. Avec les WebExtensions, la unsafeWindow est disponible par l'intermédiaire de wrappedJSObject à la place. toutes les fonctions d'aide à l'exportation sont également disponibles.

En apprendre plus

les éléments UI

Les deux technologies fournissent des API pour créer une interface utilisateur pour votre extension. Les options d'interface utilisateur pour les  WebExtensions sont plus limitées.

Elément UI Add-on SDK WebExtensions
Boutton ui/button/action browser_action / page_action
Boutton à bascule ui/button/toggle browser_action / page_action
Barre d'outils ui/toolbar None
Barre latérale ui/sidebar sidebar_action
Panneau panel browser_action / page_action popup
Menu contextuel context-menu contextMenus

Panneaux et fenêtres contextuelles

Les panneaux et les fenêtres contextuelles sont des boites de dialogue transitoires spécifiées à l'aide de HTML, CSS, et JavaScript.

Contrairement aux panneaux, les fenêtres contextuelles sont toujours attachés à un bouton (une action de navigateur ou une action de page) et ne peuvent pas être affichés par programmation : ils ne s'affichent que lorsque l'utilisateur clique sur le bouton.

Aussi, contrairement aux panneaux, les scripts des fenêtres contextuels ont accès à toutes les mêmes API que les scripts d'arrière plan. Ils peuvent même accéder directement à la page d'arrière plan, via  runtime.getBackgroundPage().

Paramètres

L'Add-on SDK et les WebExtensions bénéficient d'un certain soutien pour les paramètres (parfois aussi appelés options ou préférences).

Dans le SDK, vous pouvez définir des préférences en utilisant une clé de préférences dans package.json. L'utilisateur peut voir et modifier ces préférences dans l'entrée de l'extension dans le Gestionnaire de modules de l'extension. L'extension à son tour peut écouter les changements à l'aide de l'API simple-prefs.

Dans les WebExtensions, vous devrez implémenter votre propre UI pour présenter les paramètres et votre propre code pour les persévérer pour votre extension. Vous faites cela en écrivant un fichier HTML qui présente les paramètres UI, qui peut inclure un script pour la persistance des paramètres. Le script a accès à toutes les API des WebExtensions, et il est généralement prévu que vous devriez utiliser l'API de stockage pour mémoriser les paramètres.

Vous affectez ensuite l'URL du fichier HTML à la clé options_ui dans manifest.json. Votre page de paramètres apparaît alors dans l'entrée de l'extension dans le Gestionnaire de modules des extensions. La page d'options peut également être ouverte par programmation avec un appel API à browser.runtime.openOptionsPage.

Notez que les WebExtensions ne vous permettent pas d'accéder aux préférences du navigateur (c'est-à-dire les préférences exposées dans le SDK par preferences/service).

En apprendre plus

Internationalisation

L'extension SDK et les WebExtensions comprennent tous les deux des outils de localisation le texte visible par l'utilisateur. ils offrent principalement des fonctionnalités similaires :

Fonctions Add-on SDK WebExtensions
Strings dans add-on scripts Yes Yes
Strings dans content scripts No Yes
Strings dans HTML Yes No
Strings dans CSS No Yes
Titre & description Yes Yes
Les formulaires pluriels Yes No
Les espaces réservés Yes Yes

Dans les deux systèmes, vous fournissez des chaînes localisées en tant que collection de fichiers, une pour chaque locale.

Pour récupérer les chaînes localisées dans le code d'extension, il existe une API en JavaScript - l10n dans le SDK et i18n in les WebExtensions - qui  renvoie une chaîne localisée avec une ID.

Les WebExtensions n'ont pas de support direct pour localiser les chaînes apparaissant en HTML, donc vous devez le faire vous-même, en utilisant Javascript pour récupérer des chaînes localisées et pour remplacer le HTML par la version localisée.

En apprendre plus

Outil de ligne de commande

Le SDK de l'extension est livré avec un outil de ligne de commande, jpm, que vous pouvez utiliser pour tester et étendre les extensions. Il existe un outil équivalent pour WebExtensions, appelé web-ext. Web-ext ne supporte pas toutes les mêmes commandes que jpm, mais il possède les bases : exécuter, construire, et signer.

Il est maintenant possible d'installer (et de recharger) des extensions SDK et les extensions construites avec les API WebExtension dans Firefox à partir de leur répertoire source, sans avoir besoin de les mettre en mode XPI. Voir l'installation temporaire dans Firefox.

En apprendre plus

Les APIs JavaScript

Dans les SDK et WebExtensions, la principale puissance de l'extension provient d'un ensemble d'API JavaScript dédiées. Pour la plupart des API SDK de haut niveau, il existe un équivalent WebExtensions.

Une grande limitation de WebExtensions par rapport au SDK est que les modules complémentaires SDK peuvent nécessiter ("chrome") pour accéder à la gamme complète des API XPCOM dans Firefox. Ceci n'est pas possible avec WebExtensions.

Pour accéder aux API privilégiées dans le SDK, vous utilisez require ():

var tabs = require("sdk/tabs");
tabs.open("https://developer.mozilla.org/");

Avec WebExtensions, la plupart des API sont déjà disponibles, sans avoir besoin de les importer:

browser.tabs.create({
  "url": "https://developer.mozilla.org/"
});

Pour certaines API WebExtension, vous devez d'abord demander la permission, en utilisant la clé des permissions de manifest.json. Dans l'exemple ci-dessous, l'extension doit demander l'autorisation "tabs" si elle souhaite accéder à l'URL de l'onglet:

manifest.json:

...

"permissions": [
    "tabs"
  ]

...

Script de fond :

function logUrl(tabs) {
 console.log(tabs[0].url);
}

var querying = browser.tabs.query(
  {active: true, currentWindow: true}
);

querying.then(logUrl);

Add-on SDK => WebExtensions

Les tableaux de cette section répertorient chaque API SDK et décrivent ce que serait l'API WebExtensions équivalente, s'il y en a une implémentée dans l'édition développeur actuelle.

Le premier tableau couvre les API SDK de haut niveau, le second couvre les API bas niveau.

APIs de haut niveau

Add-on SDK WebExtensions
addon-page Use tabs.create() to load pages packaged with your add-on into normal browser tabs.
base64 window.atob() and btoa()
clipboard document.execCommand without using select() and similar in the background page.
context-menu contextMenus
hotkeys commands
indexed-db window.indexedDB
l10n i18n
notifications notifications
page-mod content_scripts
page-worker Use the background page, or load remote iframes into the background page.
panel See UI elements above.
passwords Experimental logins API
private-browsing Tab.incognito and Window.incognito.
querystring window.URLSearchParams
request window.fetch or window.XMLHttpRequest
selection Use a content script that sends the selection data to the add-on. Alternatively, if you can use a contextmenu on a selection, the selection is contained in selectionText (see contextMenus.OnClickData).
self runtime.getManifest() and extension.getURL() for data.url()
simple-prefs storage and options_ui
simple-storage storage
system Partly provided by runtime.
tabs tabs
timers alarms
ui See UI elements above.
url window.URL
widget None
windows windows

APIs bas niveau

Add-on SDK WebExtensions
loader None
chrome None
console/plain-text None
console/traceback None
content/content None
content/loader None
content/mod None
content/symbiont None
content/worker None
core/heritage None
core/namespace None
core/promise Promise
dev/panel None
event/core None
event/target None
frame/hidden-frame None
frame/utils None
fs/path None
io/byte-streams None
io/file None
io/text-streams None
lang/functional None
lang/type None
loader/cuddlefish None
loader/sandbox None
net/url None
net/xhr window.fetch or window.XMLHttpRequest
places/bookmarks bookmarks
places/favicon None
places/history history
platform/xpcom None
preferences/event-target None
preferences/service None
remote/child None
remote/parent None
stylesheet/style None
stylesheet/utils None
system/child_process runtime.connectNative
system/environment None
system/events None
system/runtime None
system/xul-app None
tabs/utils None
ui/button/action browser_action / page_action
ui/button/toggle browser_action / page_action
ui/frame None
ui/id None
ui/sidebar sidebarAction in development
ui/toolbar None
util/array None
util/collection None
util/deprecate None
util/list None
util/match-pattern None
util/object None
util/uuid None
window/utils None

Étiquettes et contributeurs liés au document

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