• Skip to main content
  • Select language
  • Skip to search
MDN Web Docs
  • Technologies
    • HTML
    • CSS
    • JavaScript
    • Graphics
    • HTTP
    • APIs / DOM
    • WebExtensions
    • MathML
  • References & Guides
    • Learn web development
    • Tutorials
    • References
    • Developer Guides
    • Accessibility
    • Game development
    • ...more docs
Add-ons
  1. MDN
  2. Mozilla
  3. Add-ons
  4. Add-on SDK
  5. Guides
  6. Multiprocess Firefox and the SDK

Multiprocess Firefox and the SDK

In This Article
  1. The SDK contract
  2. Testing your add-on
    1. Getting multiprocess Firefox
    2. Testing with shims enabled
    3. Testing with shims disabled
  3. Common problems and solutions
    1. Direct access to web content
    2. Usage of certain XPCOM APIs
    3. SDK internal incompatibilities
  4. Examples
    1. Using nsIContentPolicy with "remote/parent"
      1. Original version
      2. Ported version

Add-ons using the techniques described in this document are considered a legacy technology in Firefox. Don't use these techniques to develop new add-ons. Use WebExtensions instead. If you maintain an add-on which uses the techniques described here, consider migrating it to use WebExtensions.

From Firefox 53 onwards, no new legacy add-ons will be accepted on addons.mozilla.org (AMO).

From Firefox 57 onwards, WebExtensions will be the only supported extension type, and Firefox will not load other types.

Even before Firefox 57, changes coming up in the Firefox platform will break many legacy extensions. These changes include multiprocess Firefox (e10s), sandboxing, and multiple content processes. Legacy extensions that are affected by these changes should migrate to WebExtensions if they can. See the "Compatibility Milestones" document for more.

A wiki page containing resources, migration paths, office hours, and more, is available to help developers transition to the new technologies.

This article explains how developers can test whether SDK-based add-ons are compatible with multiprocess Firefox, and how to fix them if they are not.

The project to make Firefox multiprocess is also known as "electrolysis" or "e10s". For much more information, see the multiprocess Firefox pages.

Firefox is moving to a multiprocess architecture in which it uses one operating system process for the browser UI (also known as the chrome process), and another process to execute code running in web pages (also known as the content process).

The main compatibility consequence of this is that code running in the chrome process will no longer get direct access to web content.

Because SDK add-ons run in the chrome process (except for their content scripts):

  • code (outside content scripts) that directly accesses web content will not work
  • code that uses certain XPCOM APIs, via require("chrome"), might no longer work
  • internal problems in the SDK itself may break your add-on.

The SDK contract

The SDK makes this promise to add-on developers:

  • High-level APIs will just work in multiprocess Firefox. If they don't, it's an SDK bug.
  • Low-level APIs might not work. If you're using low-level APIs, review your use of them, test, and potentially refactor.

In practice most low-level APIs will work fine, but low-level APIs that give direct access to web content will not work.

Testing your add-on

To ease the transition for add-on developers, we've provided add-ons with compatibility shims for many APIs. With these shims in place, code that you would not expect to work in multiprocess Firefox - for example, code that directly accesses web content - will still work.

These shims use wrappers called Cross Process Object Wrappers, to make it look as if code in one process can directly access objects in a different process.

However, these shims are just a temporary migration aid, not a permanent solution. You should aim to make your add-on work without the shims.

Also, the shims don't fix all possible problems, so even a shimmed add-on may not work with multiprocess Firefox.

So the process for making your add-on multiprocess compatible is:

  • get a multiprocess version of Firefox
  • test it with the shims enabled, and fix any problems
  • test it with the shims disabled, and fix any problems.

Getting multiprocess Firefox

First, download and install Firefox Nightly or Firefox Developer Edition. Both these versions are multiprocess by default. You can enable/disable multiprocess Firefox in "about:preferences":

You can double-check that you're running multiprocess Firefox by hovering over the name of a tab: multiprocess Firefox will say "- e10s" after the tab title:

Testing with shims enabled

By default, your add-on is given the compatibility shims. So if you just test your add-on on multiprocess Firefox, you're testing it with the shims active.

You might still see some problems: the shims don't cover everything. You might also see bad performance, as the shims can be bad for responsiveness.

Testing with shims disabled

To test whether an add-on works without the shims, include the "multiprocess" permission in your package.json:

"permissions": {
    "multiprocess": true
}

Setting this permission will disable the shims for your add-on, so you can test to see if it's really multiprocess compatible or not.

Common problems and solutions

Direct access to web content

The most common problem is if you are directly accessing web content, using a low-level API like window/utils. For example:

var contentDocument = require("sdk/window/utils")
  .getMostRecentBrowserWindow().content.document;

If all you need to do is access and modify web pages, the best alternative here is just to do it in a content script, loaded using page-mod or tabs.attach().

Usage of certain XPCOM APIs

More subtly, if you're using any low-level APIs, and especially if you are using require("chrome") to get access to underlying XPCOM APIs, then it's definitely worth reviewing the Limitations of chrome scripts document. This lists APIs and patterns that used to work in the chrome process, that will no longer work. The general solution to this class of problem is to use the API in the content process.

For example: some add-ons, like ad-blockers, want to use nsIContentPolicy to register a content policy. In multiprocess Firefox, if you register the nsIContentPolicy in the chrome process then it will never see any attempts to load web content, because they happen in the content process. Instead, you must register the content policy in the content process.

For an SDK add-on, the best way to do this is to use the SDK's remote/parent module to load modules into the content process. For an example of how to do this, see Using nsIContentPolicy with remote/parent.

SDK internal incompatibilities

Unfortunately, the SDK itself isn't completely multiprocess-compatible. This means that if you disable shims for your add-on, then it might not work, even if you are only using high-level APIs. For example:

var selection = require("sdk/selection");
function myListener() {
  console.log(selection.text);
}
selection.on('select', myListener);

This add-on will not work if you've set the "multiprocess" permission, because sdk/selection depends on the shims. If this is the case for you, there's nothing you can do to fix it apart from using a different API.

We're working on fixing these problems: see bug 1004745 and its dependencies.

Examples

Using nsIContentPolicy with "remote/parent"

This example shows how to use the "remote/parent" module to register a content policy in the content process.

The add-on consists of three files:

  • package.json
  • index.js
  • content-policy.js

Original version

In the original version, the "package.json" file can just be the default file generated by jpm init.

The index.js looks like this:

require("sdk/preferences/service").set("extensions.@content-policy-sdk.sdk.console.logLevel", "all");
console.log("running");
var policy = require('./content-policy');
policy.init();

This just makes sure logging is enabled for the add-on (we would need to remove this in production, of course), then loads the "content-policy" module, then calls its init() export.

Most of the work is in "content-policy.js":

var {components, Cu, Cc, Ci} = require("chrome");
var unload = require("sdk/system/unload");
Cu.import("resource://gre/modules/XPCOMUtils.jsm");
Cu.import("resource://gre/modules/Services.jsm");
let policy =
{
  classDescription: "Test content policy",
  classID: components.ID("{12345678-1234-1234-1234-123456789abc}"),
  contractID: "@adblockplus.org/test-policy;1",
  xpcom_categories: ["content-policy"],
  init: function()
  {
    let registrar = components.manager.QueryInterface(Ci.nsIComponentRegistrar);
    registrar.registerFactory(this.classID, this.classDescription, this.contractID, this);
    let catMan = Cc["@mozilla.org/categorymanager;1"].getService(Ci.nsICategoryManager);
    for each (let category in this.xpcom_categories)
      catMan.addCategoryEntry(category, this.contractID, this.contractID, false, true);
    unload.when(
    (function()
    {
      for each (let category in this.xpcom_categories)
        catMan.deleteCategoryEntry(category, this.contractID, false);
      // This needs to run asynchronously, see bug 753687
      Services.tm.currentThread.dispatch(function()
      {
        registrar.unregisterFactory(this.classID, this);
      }.bind(this), Ci.nsIEventTarget.DISPATCH_NORMAL);
    }).bind(this));
  },
  // nsIContentPolicy interface implementation
  shouldLoad: function(contentType, contentLocation, requestOrigin, node, mimeTypeGuess, extra)
  {
    if (contentLocation.schemeIs("http") || contentLocation.schemeIs("https")) {
      console.log("shouldLoad: " + contentType + " " +
                            (contentLocation ? contentLocation.spec : "null") + " " +
                            (requestOrigin ? requestOrigin.spec : "null") + " " +
                            node + " " +
                            mimeTypeGuess + "\n");
    }
    return Ci.nsIContentPolicy.ACCEPT;
  },
  shouldProcess: function(contentType, contentLocation, requestOrigin, node, mimeTypeGuess, extra)
  {
    return Ci.nsIContentPolicy.ACCEPT;
  },
  // nsIFactory interface implementation
  createInstance: function(outer, iid)
  {
    if (outer)
      throw Cr.NS_ERROR_NO_AGGREGATION;
    return this.QueryInterface(iid);
  },
  // nsISupports interface implementation
  QueryInterface: XPCOMUtils.generateQI([Ci.nsIContentPolicy, Ci.nsIFactory])
};
exports.init = function() {
  policy.init();
}

This is a slightly adapted version of the example policy written by Wladimir Palant in a stackoverflow answer. The policy just listens for attempts to load content, then if they are using an "http" or "https" scheme, logs some information about them.

You can build this into an add-on, and it will work fine in singleprocess Firefox. In the Browser Console, you'll see messages being logged as you load pages.

Because we haven't set the "multiprocess" permission in package.json, it will work fine in multiprocess Firefox as well, because nsIContentPolicy is shimmed.

Ported version

First, set the "multiprocess" permission by adding a key like this in package.json:

  "permissions": {
    "multiprocess": true
  }

Now try running the add-on in multiprocess Firefox. You should no longer see any output in the Browser Console, because you registered the content policy in the chrome process, but the loads are happening in the content process.

So let's make it work again. The new index.js should look like this:

require("sdk/preferences/service").set("extensions.@content-policy-sdk.sdk.console.logLevel", "all");
console.log("running");
const { processes, remoteRequire } = require("sdk/remote/parent");
remoteRequire("./content-policy", module);
// For every current and future process
processes.forEvery(process => {
  process.port.emit("init");
});

The first two lines are the same as the old version.

After that, we're:

  • importing processes and remoteRequire() from "sdk/remote/parent"
  • loading "content-policy.js" into the content process, using remoteRequire()
  • sending an "init" message to "content-policy.js", using the processes object.

The new "content-policy.js" looks like this:

var {components, Cu, Cc, Ci} = require("chrome");
var unload = require("sdk/system/unload");
Cu.import("resource://gre/modules/XPCOMUtils.jsm");
Cu.import("resource://gre/modules/Services.jsm");
let policy =
{
  classDescription: "Test content policy",
  classID: components.ID("{12345678-1234-1234-1234-123456789abc}"),
  contractID: "@adblockplus.org/test-policy;1",
  xpcom_categories: ["content-policy"],
  init: function()
  {
    let registrar = components.manager.QueryInterface(Ci.nsIComponentRegistrar);
    registrar.registerFactory(this.classID, this.classDescription, this.contractID, this);
    let catMan = Cc["@mozilla.org/categorymanager;1"].getService(Ci.nsICategoryManager);
    for each (let category in this.xpcom_categories)
      catMan.addCategoryEntry(category, this.contractID, this.contractID, false, true);
    unload.when(
    (function()
    {
      for each (let category in this.xpcom_categories)
        catMan.deleteCategoryEntry(category, this.contractID, false);
      // This needs to run asynchronously, see bug 753687
      Services.tm.currentThread.dispatch(function()
      {
        registrar.unregisterFactory(this.classID, this);
      }.bind(this), Ci.nsIEventTarget.DISPATCH_NORMAL);
    }).bind(this));
  },
  // nsIContentPolicy interface implementation
  shouldLoad: function(contentType, contentLocation, requestOrigin, node, mimeTypeGuess, extra)
  {
    if (contentLocation.schemeIs("http") || contentLocation.schemeIs("https")) {
      console.log("shouldLoad: " + contentType + " " +
                            (contentLocation ? contentLocation.spec : "null") + " " +
                            (requestOrigin ? requestOrigin.spec : "null") + " " +
                            node + " " +
                            mimeTypeGuess + "\n");
    }
    return Ci.nsIContentPolicy.ACCEPT;
  },
  shouldProcess: function(contentType, contentLocation, requestOrigin, node, mimeTypeGuess, extra)
  {
    return Ci.nsIContentPolicy.ACCEPT;
  },
  // nsIFactory interface implementation
  createInstance: function(outer, iid)
  {
    if (outer)
      throw Cr.NS_ERROR_NO_AGGREGATION;
    return this.QueryInterface(iid);
  },
  // nsISupports interface implementation
  QueryInterface: XPCOMUtils.generateQI([Ci.nsIContentPolicy, Ci.nsIFactory])
};
const { process } = require("sdk/remote/child");
process.port.on("init", () => {
  policy.init();
});

This is exactly the same as the last version, except for the last few lines, where we:

  • import the process object from "sdk/remote/child"
  • use process to listen for the "init" message from the other side, and call our policy.init() function when that happens.

That's it. Now we can run the add-on in multiprocess Firefox, and it will work without needing any shims.

Document Tags and Contributors

Tags: 
  • Firefox OS
  • Guide
  • SDK
 Contributors to this page: wbamberg, ChimeraCoder, evold, kscarfone
 Last updated by: wbamberg, Dec 1, 2016, 10:12:08 AM
See also
  1. WebExtensions
  2. Getting started
    1. What are WebExtensions?
    2. Your first WebExtension
    3. Your second WebExtension
    4. Anatomy of a WebExtension
    5. Example WebExtensions
  3. How to
    1. Intercept HTTP requests
    2. Modify a web page
    3. Add a button to the toolbar
    4. Implement a settings page
  4. Concepts
    1. Using the JavaScript APIs
    2. User interface components
    3. Content scripts
    4. Match patterns
    5. Internationalization
    6. Content Security Policy
    7. Native messaging
  5. Porting
    1. Porting a Google Chrome extension
    2. Porting a legacy Firefox add-on
    3. Embedded WebExtensions
    4. Comparison with the Add-on SDK
    5. Comparison with XUL/XPCOM extensions
    6. Chrome incompatibilities
  6. Firefox workflow
    1. Temporary Installation in Firefox
    2. Debugging
    3. Getting started with web-ext
    4. web-ext command reference
    5. WebExtensions and the Add-on ID
    6. Publishing your WebExtension
  7. JavaScript APIs
    1. Browser support for JavaScript APIs
    2. alarms
    3. bookmarks
    4. browserAction
    5. browsingData
    6. commands
    7. contextMenus
    8. contextualIdentities
    9. cookies
    10. downloads
    11. events
    12. extension
    13. extensionTypes
    14. history
    15. i18n
    16. identity
    17. idle
    18. management
    19. notifications
    20. omnibox
    21. pageAction
    22. runtime
    23. sessions
    24. sidebarAction
    25. storage
    26. tabs
    27. topSites
    28. webNavigation
    29. webRequest
    30. windows
  8. Manifest keys
    1. applications
    2. author
    3. background
    4. browser_action
    5. chrome_url_overrides
    6. commands
    7. content_scripts
    8. content_security_policy
    9. default_locale
    10. description
    11. developer
    12. homepage_url
    13. icons
    14. manifest_version
    15. name
    16. omnibox
    17. options_ui
    18. page_action
    19. permissions
    20. short_name
    21. sidebar_action
    22. version
    23. web_accessible_resources
  9. Add-on SDK
  10. Getting started
    1. Installation
    2. Getting started
    3. Troubleshooting
  11. High-Level APIs
    1. addon-page
    2. base64
    3. clipboard
    4. context-menu
    5. hotkeys
    6. indexed-db
    7. l10n
    8. notifications
    9. page-mod
    10. page-worker
    11. panel
    12. passwords
    13. private-browsing
    14. querystring
    15. request
    16. selection
    17. self
    18. simple-prefs
    19. simple-storage
    20. system
    21. tabs
    22. timers
    23. ui
    24. url
    25. webextension
    26. widget
    27. windows
  12. Low-Level APIs
    1. /loader
    2. chrome
    3. console/plain-text
    4. console/traceback
    5. content/content
    6. content/loader
    7. content/mod
    8. content/symbiont
    9. content/worker
    10. core/heritage
    11. core/namespace
    12. core/promise
    13. dev/panel
    14. event/core
    15. event/target
    16. frame/hidden-frame
    17. frame/utils
    18. fs/path
    19. io/byte-streams
    20. io/file
    21. io/text-streams
    22. lang/functional
    23. lang/type
    24. loader/cuddlefish
    25. loader/sandbox
    26. net/url
    27. net/xhr
    28. places/bookmarks
    29. places/favicon
    30. places/history
    31. platform/xpcom
    32. preferences/event-target
    33. preferences/service
    34. remote/child
    35. remote/parent
    36. stylesheet/style
    37. stylesheet/utils
    38. system/child_process
    39. system/environment
    40. system/events
    41. system/runtime
    42. system/unload
    43. system/xul-app
    44. tabs/utils
    45. test/assert
    46. test/harness
    47. test/httpd
    48. test/runner
    49. test/utils
    50. ui/button/action
    51. ui/button/toggle
    52. ui/frame
    53. ui/id
    54. ui/sidebar
    55. ui/toolbar
    56. util/array
    57. util/collection
    58. util/deprecate
    59. util/list
    60. util/match-pattern
    61. util/object
    62. util/uuid
    63. window/utils
  13. Firefox for Android
  14. Getting started
    1. Walkthrough
    2. Debugging
    3. Code snippets
  15. APIs
    1. Accounts.jsm
    2. BrowserApp
    3. HelperApps.jsm
    4. Home.jsm
    5. HomeProvider.jsm
    6. JavaAddonManager.jsm
    7. NativeWindow
    8. Notifications.jsm
    9. PageActions.jsm
    10. Prompt.jsm
    11. RuntimePermissions.jsm
    12. Snackbars.jsm
    13. Sound.jsm
    14. Tab
  16. Legacy
  17. Restartless extensions
    1. Overview
  18. Overlay extensions
    1. Overview
  19. Themes
  20. Lightweight themes
    1. Overview
  21. Complete themes
    1. Overview
  22. Publishing add-ons
  23. Guides
    1. Signing and distribution overview
    2. Submit an add-on
    3. Review policies
    4. Developer agreement
    5. Featured add-ons
    6. Contact addons.mozilla.org
  24. Community and support
  25. Channels
    1. Add-ons blog
    2. Add-on forums
    3. Stack Overflow
    4. Development newsgroup
    5. IRC Channel