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.
Advantages of the SDK
| Simplicity |
The SDK provides high-level JavaScript APIs to simplify many common tasks in add-on development, and tool support which greatly simplifies the process of developing, testing, and packaging an add-on. |
| Compatibility |
Although we can't promise we'll never break a High-Level API, maintaining compatibility across Firefox versions is a top priority for us. We've designed the APIs to be forward-compatible with the new multiple process architecture (codenamed Electrolysis) planned for Firefox. We also expect to support both desktop and mobile Firefox using a single edition of the SDK: so you'll be able to write one extension and have it work on both products. |
| Security |
If they're not carefully designed, Firefox add-ons can open the browser to attack by malicious web pages. Although it's possible to write insecure add-ons using the SDK, it's not as easy, and the damage that a compromised add-on can do is usually more limited. |
| Restartlessness |
Add-ons built with the SDK can be installed without having to restart Firefox. Although you can write traditional add-ons that are restartless, you can't use XUL overlays in them, so most traditional add-ons would have to be substantially rewritten anyway. |
| User Experience Best Practices |
The UI components available in the SDK are designed to align with the usability guidelines for Firefox, giving your users a better, more consistent experience. |
| Mobile Support |
Starting in SDK 1.5, we've added experimental support for developing add-ons on the new native version of Firefox Mobile. See the tutorial on mobile development. |
Advantages of XUL-based Add-ons
| User interface flexibility |
XUL overlays offer a great deal of options for building a UI and integrating it into the browser. Using only the SDK's supported APIs you have much more limited options for your UI. |
| XPCOM |
Traditional add-ons have access to a vast amount of Firefox functionality via XPCOM. The SDK's supported APIs expose a relatively small set of this functionality. |
Low-level APIs and Third-party Modules
That's not the whole story. If you need more flexibility than the SDK's High-Level APIs provide, you can use its Low-level APIs to load XPCOM objects directly or to manipulate the DOM directly as in a traditional bootstrapped extension.
Alternatively, you can load third-party modules, which extend the SDK's core APIs.
Note that by doing this you lose some of the benefits of programming with the SDK including simplicity, compatibility, and to a lesser extent security.