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.
Starting from Firefox 53, no new legacy add-ons will be accepted on addons.mozilla.org (AMO) for desktop Firefox and Firefox for Android.
Starting from Firefox 57, only extensions developed using WebExtensions APIs will be supported on Desktop Firefox and Firefox for Android.
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 use WebExtensions APIs if they can. See the "Compatibility Milestones" document for more information.
A wiki page containing resources, migration paths, office hours, and more, is available to help developers transition to the new technologies.
In an add-on's main scripts you can't do that, because the add-on code does not execute in the context of a page, and the DOM is therefore not available. If you need to access the DOM of a particular page, you need to use a content script.
This is the place where the main logic of your add-on is implemented.
Your add-on is implemented as a collection of one or more CommonJS modules. Each module is supplied as a script stored under the
lib directory under your add-on's root directory.
Minimally you'll have a single module implemented by a script called "main.js", but you can include additional modules in
lib, and import them using the
require() function. To learn how to implement and import your own modules, see the tutorial on Implementing Reusable Modules.
While your add-on will always have a "main.js" module, you will only need to write content scripts if your add-on needs to manipulate web content. Content scripts are injected into web pages using APIs defined by some of the SDK's modules such as
Content scripts may be supplied as literal strings or maintained in separate files and referenced by filename. If they are stored in separate files you should store them under the
data directory under your add-on's root.
To learn all about content scripts read the Working with Content Scripts guide.
API Access for Add-on Code and Content Scripts
The table below summarizes the APIs that are available to each type of script.
|API||Add-on code||Content script|
|The console global supplied by the SDK.||✔||✔|
|Globals defined by the HTML5 specification, such as