XUL/XPCOM 拡張機能との比較


この記事は WebExtensions テクノロジーと、直接 XUL を操作して XPCOM にアクセスする「古典的な」拡張機能との技術的な比較です。こうしたアドオンを保守していて、WebExtension API を使うものに移植しようとしている人に役立つことを目指します。

この記事は overlay extensionsbootstrapped extensions をカバーし、Add-on SDK を使って開発された拡張機能はカバーしません。Add-on SDK については、Comparison with the Add-on SDK を見てください。

とても基本的なレベルとして、XUL/XPCOM 拡張機能は WebExtensions で開発される拡張機能と似ています。両方とも次のものを含んでいます:

  • 拡張機能のメタデータとそのふるまいのいくらかを含むマニフェストファイル
  • 特権 JavaScript API にアクセスする JavaScript コードと、拡張機能が有効な間ロードされたままになる JavaScript コード
  • 特定の UI 要素、例えばボタンを、ブラウザーに追加できること


  • XUL/XPCOM 拡張機能と比較して、WebExtensions では拡張機能の UI に多くの制限がかかっていて、特権 JavaScript API のセットも制限されています。
  • WebExtensions では別々のスクリプトをウェブページに挿入してメッセージ API経由でそれらが通信することでのみ、ウェブコンテンツにアクセスできます (しかし、注意として、XUL/XPCOM 拡張機能がマルチプロセス Firefox で動作する時でも同じです)。


XUL/XPCOM 拡張機能には 2 つのマニフェストファイルがあります:

  • install.rdf には拡張機能のメタデータ、例えば名前、アイコンなどが入ります。
  • chrome.manifest、これにより Firefox は拡張機能のコンポーネントの場所を見つけることができて、それには拡張機能のインターフェイスとしての XUL o オーバーレイや、ふるまいとしてのスクリプトや、ローカライズされた文字列を格納したファイルが含まれます。

WebExtensions には manifest.json という単一のマニフェストがあり、似た目的です。これを使って Firefox に追加するボタンの指定や実行スクリプトを一覧するのと同様に、拡張機能の名前、説明、アイコンなどを指定します。WebExtension APIs を使用して開発する拡張機能のコンポーネントを概観して、それが manifest.json でどう指定されるかは、「拡張機能の中身」を見てください。



XUL/XPCOM extensions can build their UI by directly manipulating the XUL used to specify the browser's own UI. They do this either using overlays or, in the case of bootstrapped/restartless extensions, using JavaScript to modify the XUL document. They can not only add any elements to the browser's UI, they can also modify or remove existing elements. They can also use APIs like CustomizableUI.jsm to build their UI.

Extensions built with WebExtension APIs don't get this kind of direct access. Instead, a combination of manifest.json keys and JavaScript APIs enable them to add a limited set of UI components to the browser. The available components are:

名前 説明 Specified using
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


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 の同等品
nsIAndroidBridge なし
nsIAppShellService なし
nsIBlocklistService なし
nsICacheService なし
nsICacheStorageService なし
nsIClipboard Partial: see the clipboard API, and Interacting with the clipboard.
nsIConsoleService window.console
nsIContentPrefService なし
nsICookieManager2 cookies
nsIMessageSender Content scripts
CrashManager.jsm なし
nsIDOMStorageManager なし
nsIDOMRequestService なし
nsIDownloadManager downloads
nsIDroppedLinkHandler なし
nsIEventListenerService なし
nsIEffectiveTLDService なし
nsIFocusManager なし
nsILocaleService i18n
nsILoginManager なし
nsIWinMetroUtils なし
Content scripts
nsIObserverService なし
nsIPermissionManager なし
Content scripts
See Settings.
nsIPromptService なし
mozIJSSubScriptLoader なし
nsIScriptSecurityManager なし
nsIBrowserSearchService なし
nsIAppStartup なし
mozIStorageService storage
nsIStringBundleService i18n
nsIPropertyBag2 なし
nsITelemetry なし
nsIThreadManager なし
nsIURIFixup なし
nsIURLFormatter なし
nsIVersionComparator なし
nsIWindowMediator なし
nsIWindowWatcher なし



Historically, XUL/XPCOM extensions have been able to get direct access to web content. 例えば、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 既定では: 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.



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.



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.
Some browser-specific preferences can however still be controlled through the browser.browserSettings or browser.privacy API.



このページの貢献者: mdnwebdocs-bot, Uemmra3
最終更新者: mdnwebdocs-bot,