We are planning to deprecate the use by Firefox add-ons of the techniques described in this document.

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 instead.

Add-ons developed using these techniques might not work with multiprocess Firefox (e10s), which is already the default in Firefox Nightly and Firefox Developer Edition, and will soon be the default in Beta and Release versions of Firefox. We have documentation on making your add-ons multiprocess-compatible, but it will be more future-proof for you to migrate to WebExtensions.

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

You should avoid using the API if at all possible. We intend to deprecate it in future releases.

If you use this API you can expect your add-on to get an extra security review by

This module should not be confused with the "chrome" global variable that WebExtensions can use to access APIs.

The chrome module gives an Add-on SDK add-on access to the Components object, which in turn gives it access to a large set of privileged low-level Firefox APIs.

chrome is a built-in pseudo module of the toolkit loader. See the chrome authority tutorial for more details.

You can see an example of using this API in the XUL Migration Guide.

Document Tags and Contributors

 Contributors to this page: wbamberg, maybe
 Last updated by: wbamberg,