Modules

Comparaison avec les extensions XUL/XPCOM

Cette traduction est incomplète. Aidez à traduire cet article depuis l'anglais.

Cet article est une comparaison technique entre la technologie WebExtensions et les extensions "classiques" développées à l'aide de la manipulation XUL directe et de l'accès direct à XPCOM. Il est destiné à aider les personnes qui maintiennent un add-on comme celui-ci, et qui envisagent de porter pour utiliser les APIs WebExtension.

Cet article couvre à la fois les extensions de superposition et les extensions bootstrap, mais pas les extensions développées à l'aide du SDK Add-on. Pour le SDK Add-on, regarder la Comparaison avec les Add-on SDK.

A un niveau très basique, les extensions XUL/XPCOM sont similaires aux extensions développées avec WebExtensions. Ils incluent tous deux:

  • Fichiers manifest définissant des métadonnées pour l'extensions et certains aspect de son comportement.
  • Le code JavaScript qui accède à un ensemble d'API JavaScript privilégiées et qui reste chargé aussi longtemps que l'extension elle-même est activée.
  • La possibilité d'ajouter des éléments spécifiques UI, tels que des boutons au navigateur.

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

  • 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 limité d'API JavaScript privilégiées.
  • Les WebExtensions ne peuvent 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 (notez que cela est également vrai des extensions XUL/XPCOM qui s'attendent à fonctionner avec le multiprocessus de Firefox).

Manifest

Les extensions XUL/XPCOM  ont deux fichiers manifest :

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

WebExtensions possède un fichier manifest unique appelé manifest.json, qui a un but similaire. Vous l'utilisez pour spécifier le nom de l'extension, la description, les icônes, etc., ainsi que pour spécifier les boutons ajoutés à Firefox et pour répertorier les scripts qu'il doit exécuter. Pour obtenir un aperçu des composants d'une extension développée à l'aide des APIs WebExtension, et comment elles sont spécifiées dans manifest.json, voir  "Anatomie d'une extension".

En apprendre 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. Ils le font en utilisant des superpositions ou dans le cas d'extensions bootstrap/sans relâche, en utilisant Javascript pour modifier le document XUL. Ils peuvent non seulement ajouter des éléments à l'interface utilisateur du navigateur, mais aussi modifier ou supprimer des éléments existants. Ils peuvent également utiliser des API comme CustomizableUI.jsm pour créer leur interface utilisateur.

Les extensions construites avec les APIs WebExtensions n'obtiennent pas ce type d'accès direct. Au lieu de cela, une conbinaison de clés manifest.json et d'API JavaScript leur permet d'ajouter un ensemble limité de composants UI au navigateur. Les composants disponibles sont : 

Nom Description Utilisation spécifiée
Browser action Button in the browser toolbar, with an optional popup panel.

browser_action manifest key

browserAction API

Page action Button in the URL bar, with an optional popup panel.

page_action manifest key

pageAction API

Commands Keyboard shortcuts.

commands manifest key

commands API

Context menu Adds items and submenus to the browser's context menu. contextMenus API

Privileged APIs

Both XUL/XPCOM extensions and extensions built with WebExtension APIs can contain scripts that stay loaded for as long as the extension itself is enabled, and that have access to a set of privileged APIs. However, XUL/XPCOM extensions get access to a much wider range of APIs.

The scripts packaged with XUL/XPCOM extensions get access to the full set of XPCOM APIs and JavaScript code modules through the Components object. They also get direct access to the browser's internals through globals like gBrowser.

The equivalent WebExtension scripts are called background scripts, and they get access to a much smaller set of high-level JavaScript APIs. To see all the privileged APIs available to background scripts, see the summary API page. Background scripts also get a window global, with all the DOM objects that are available in a normal web page.

There are vastly more APIs available to XUL/XPCOM extensions than are available to WebExtensions, and for many XUL/XPCOM APIs, there isn't a WebExtensions substitute. The table below lists every API in the popular Services.jsm module, describe what the equivalent WebExtensions API would be, if there is one.

You'll see that many APIs have no WebExtensions equivalent yet. However we are intending to extend the WebExtension APIs to support the needs of add-on developers, so if you have ideas, we'd love to hear them. You can reach us on the dev-addons mailing list or #webextensions on IRC.

Services.jsm API WebExtensions equivalent
nsIAndroidBridge None
nsIXULAppInfo
nsIXULRuntime
None
nsIAppShellService None
nsIBlocklistService None
nsICacheService None
nsICacheStorageService None
nsIClipboard None
nsIConsoleService window.console
nsIContentPrefService None
nsICookieManager2 cookies
nsIMessageSender Content scripts
CrashManager.jsm None
nsIDirectoryService
nsIProperties
None
nsIDOMStorageManager None
nsIDOMRequestService None
nsIDownloadManager downloads
nsIDroppedLinkHandler None
nsIEventListenerService None
nsIEffectiveTLDService None
nsIFocusManager None
nsIIOService
nsIIOService2
None
nsILocaleService i18n
nsILoginManager None
nsIWinMetroUtils None
nsIMessageBroadcaster
nsIFrameScriptLoader
Content scripts
nsIObserverService None
nsIPermissionManager None
nsIMessageBroadcaster
nsIProcessScriptLoader
Content scripts
nsIPrefBranch
nsIPrefBranch2
nsIPrefService
See Settings.
nsIPromptService None
mozIJSSubScriptLoader None
nsIScriptSecurityManager None
nsIBrowserSearchService None
nsIAppStartup None
mozIStorageService storage
nsIStringBundleService i18n
nsIPropertyBag2 None
nsITelemetry None
nsIThreadManager None
nsIURIFixup None
nsIURLFormatter None
nsIVersionComparator None
nsIWindowMediator None
nsIWindowWatcher None

Learn more

Interacting with web content

Historically, XUL/XPCOM extensions have been able to get direct access to web content. For example, they can directly access and modify the page DOM using gBrowser:

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

However, this is only possible in single-process Firefox. In multiprocess Firefox, web content and extension code run in different processes, so this direct access is no longer possible, and extensions which rely on it will break. Multiprocess Firefox is coming soon, and multiprocess compatibility will be a necessity.

XUL/XPCOM extensions can still interact with web content in multiprocess Firefox by refactoring the code that accesses web content into separate scripts called frame scripts, and using the message manager to communicate with these scripts. But this is complex and can involve deep changes to the extension's code.

WebExtensions are multiprocess-compatible by default: code that interacts with web content is factored into separate scripts called content scripts, that can communicate with the rest of the extension using a messaging API.

Learn more

Localization

In a XUL/XPCOM extension you handle localization by supplying DTD or properties for each supported language, and referring to them using locale statements inside the chrome.manifest. You can then include localized strings in UI elements or in code.

The general approach with WebExtensions is similar, but the details are all different. With WebExtensions you supply localized strings as a collection of JSON files, one for each locale.

To retrieve localized strings in extension code, use the i18n API.

WebExtensions don't have direct support for localizing strings appearing in HTML, so you have to do this yourself, using JavaScript to retrieve localized strings and to replace the HTML with the localized version.

Learn more

Settings

XUL/XPCOM extensions typically store settings using the XPCOM preferences service or the inline options system.

With WebExtensions you write an HTML file that presents the settings UI, which can include a script for persisting the settings for your extension. The script gets access to all the WebExtensions APIs, and it's generally expected that you should use the storage API to persist settings.

You then assign the HTML file's URL to the options_ui key in manifest.json. Your settings page then appears in the extension's entry in the Add-ons Manager.  The options page can also be programmatically opened with an API call to browser.runtime.openOptionsPage.

Note that WebExtensions does not give you access to the Preferences API, so you can't directly get or set the browser's own preferences.

Learn more

Étiquettes et contributeurs liés au document

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