The Mozilla platform is constantly evolving. As we add new features to the web and to our applications, programming interfaces change. The rules which govern interface changes are different depending on the consumers and the languages involved.
APIs which are visible to web content are not modified, except as a last resort when inherent security vulnerabilities or incompatibility with other browsers make it the only option. Any changes, including new features, must have super-review.
Documented APIs which are shipped as part of the Jetpack SDK are designed to work in future versions of Firefox. Achieving this compatibility may require rebuilding the extension with a new version of the Jetpack SDK.
Traditional extensions written using XUL overlays and XPCOM have access to the full power of the Mozilla platform. With the power, however, comes the understanding that the Mozilla platform is constantly changing and many APIs may change in future versions of Firefox.
Traditionally, Mozilla has maintained a set of XPCOM interfaces and functions with the @status FROZEN marking. Using these interfaces, and using dynamic calls to QueryInterface, it has been possible to write binary XPCOM components which were compatible with multiple versions of Firefox. Beginning with Mozilla 2 (Firefox 4), this will no longer be supported: all @status markings have been removed, and extensions that use binary components will need to recompile for each major version they wish to support.
- JS-ctypes is the recommended way for extensions to call into OS or third-party native code.
- If necessary, it is possible for an extension to support multiple versions by shipping multiple shared libraries (DLLs) in the same extension package, and selecting the correct version using versioning flags in its chrome.manifest file.
- JSAPI, NSPR, NSS, and other libraries which are currently shipped as separate shared libraries may be integrated into libxul, and extension authors should avoid linking against them.