There are three common methods of developing extensions: the Add-on SDK, manually bootstrapped restartless extensions, and legacy, overlay-based restartful extensions.
WebExtensions
We're working on a system called WebExtensions, which is a new way to develop WebExtensions for Firefox, that will be largely compatible with the system used by Chrome and Opera.
In the future this will be the preferred way to develop extensions for Firefox.
At the moment the implementation of this is experimental, but you can see the docs here if you want to give it a spin.
The methods are in no way mutually exclusive, and techniques from one method are often used in the others. The Add-on SDK, in particular, acts as a thin layer over the restartless extension mechanism to simplify certain tasks, and to cleanup after itself transparently. Utilities from the SDK may be used in all other extension types, and lower-level methods used by traditional extensions may be used in SDK add-ons where the SDK falls short.
In general, however, it is advisable to use an SDK-based approach when feasible, and to prefer restartless extensions to overlay-based ones.
Add-on SDK
The Add-on SDK consists of two things:
- a command-line tool to help test and package extensions
- a set of JavaScript APIs, built into Firefox, to create extensions, including APIs to build user interfaces, to interact with the browser and to interact with web content
All SDK-based extensions are restartless, and unlike "bare" restartless extensions, the SDK take care of cleanup for you when the extension is disabled or unloaded. Most of the SDK APIs are supported on both Firefox Desktop and Firefox for Android, so there's a good chance that you can use the same codebase for both targets. As long as you only use the SDK's "high level APIs", the SDK strives to maintain compatibility across Firefox versions. You don't have to learn XUL: you just need JavaScript, HTML, and CSS. The SDK is structured in modules to make it easier to structure and secure code.
The "high-level APIs" are limited in functionality. You can access low-level APIs that give you all the power of the other extension types, but you then lose the simplicity, security, and compatibility promise offered by the SDK. Unlike the other extension types, the SDK strictly separate privileged code from code that interacts with web content (which the SDK calls "content scripts"). This makes SDK extensions more secure, but adds programming complexity. Finally, the SDK only formally supports Firefox for Desktop and Firefox for Android, and no other Gecko applications.
Especially if you're new to extension development, it's advisable to develop using the SDK unless it's not suitable for your specific needs.
Learn more about the Add-on SDK.
Restartless extensions
Restartless extensions provide a more low-level way to develop extensions than the SDK.
On applications that use XUL to specify their interfaces, such as Firefox Desktop, restartless extensions typcially build user interfaces by creating and inserting XUL nodes using DOM APIs. On Firefox for Android extensions build user interfaces using APIs that wrap native Android widgets. So it is possible for restartless extensions to target the mobile browser, but they must use a different codebase to do so.
Apart from that, JavaScript code running in the extension has a similar environment to code running in a traditional overlay extension: it has automatic chrome privileges, giving it access to browser objects like tabbrowser and XPCOM.
Compared to SDK-based extensions, restartless extensions have relatively complex cleanup requirements that they must satisfy when they are disabled or uninstalled.
Learn more about restartless extensions.
Overlay extensions
The user interface for most Gecko-based applications is specified using an XML-based language called XUL. Traditional XUL extensions specify their user interface declaratively, using a "XUL overlay", which is a file containing a XUL specification that overlays the application user interface when the application is loaded.
Because the XUL overlay is applied when the application starts up, the user must restart the application when they install a traditional extension. Because Firefox for Android does not use XUL to specify its user interface, you can't use XUL overlays in Firefox for Android.
JavaScript code running in the extension is automatically granted chrome privileges, giving it access to browser objects like tabbrowser as well as XPCOM objects.
The main advantages of writing XUL overlay extensions are that XUL overlays are very powerful and can integrate very deeply with the browser's UI. Also, you can specify your interface declaratively, rather than having to construct it programmatically.
The main disadvantages are that:
- you can't use XUL overlays with Firefox for Android
- XUL is a large, complex, and Mozilla-specific technology
- the user must restart their browser after installing your extension
- compatibility of the APIs your code relies on is not guaranteed across versions of the host application
Learn more about overlay extensions.
Feature comparison
| Traditional XUL overlay | Restartless | Add-on SDK | |
|---|---|---|---|
| Ease of use |
Build user interfaces declaratively using Mozilla-specific XUL. Implement behavior with complex Firefox APIs (JSMs, XPCOM). Direct access to web content. |
Build user interfaces programmatically using Mozilla-specific XUL. Implement behavior with complex Firefox APIs (JSMs, XPCOM). Direct access to web content. |
Build user interfaces with standard technologies: HTML, CSS, and high-level JS APIs. Implement behavior with high-level, node-like JS APIs. Content script model adds complexity for interacting with content. |
| Power | Very powerful techniques for building user interfaces and behavior. | Very powerful techniques for building user interfaces and behavior. | High-level APIs are much more limited. It's possible to use most of the same powerful APIs as the other techniques, but at the cost of the other benefits (simplicity, compatibility, security). |
| Compatibility promise | No promises: APIs may change from one release to the next, although some warning is given. | No promises: APIs may change from one release to the next, although some warning is given. | Stable, smaller APIs: although changes do happen sometimes, a deprecation period is given unless absolutely impossible. |
| Restart required | Yes. | No. | No. |
| Cross-application support |
Support for any application that uses XUL to specify its user interface (Firefox Desktop, Thunderbird, SeaMonkey). No support for Firefox for Android. It's generally necessary to use different code to target different applications. |
Support for any application that uses XUL to specify its user interface (Firefox Desktop, Thunderbird, SeaMonkey). Supports Firefox for Android. It's generally necessary to use different code to target different applications. |
Support for Firefox Desktop and Firefox for Android. It's often possible to use the same codebase to target different applications. |