Firefox Add-on History: Bootstrap.js and Jetpack SDK

This article explores the pivotal transitional technologies in the history of the Firefox web browser: bootstrap.js restartless add-ons and the Jetpack Add-on SDK. Before Mozilla adopted the modern WebExtensions API, these two frameworks modernized how developers built browser extensions. They eliminated the need for annoying browser restarts, simplified the development process using standard web technologies, and laid the essential groundwork for the secure, multi-process architecture found in Firefox today.

The Precursor: XUL and Overlay Add-ons

To understand bootstrap.js and the Jetpack SDK, it is necessary to look at what preceded them. Originally, Firefox extensions were built using XUL (XML User Interface Language) and XPCOM (Cross-Platform Component Object Model).

While this system gave developers absolute power to modify almost any part of the browser, it had major drawbacks:

  • Browser Restarts: Installing, updating, or disabling an add-on required a complete browser restart to merge the add-on's XUL overlays with the browser's core interface.
  • High Complexity: Developers had to learn proprietary Mozilla technologies rather than standard web languages.
  • Fragility: Because add-ons mingled directly with Firefox’s internal code, minor browser updates frequently broke extensions.

Bootstrap.js: The Era of Restartless Add-ons

Introduced in Firefox 4 (2011), bootstrap.js was Mozilla's first major step toward modernizing the add-on ecosystem. It introduced the concept of "restartless" add-ons.

Instead of relying on XUL overlays that loaded only when the browser launched, a bootstrapped add-on contained a file named bootstrap.js in its root directory. This file defined four specific functions that Firefox would call at different points in the add-on's lifecycle:

  • install()
  • uninstall()
  • startup()
  • shutdown()

How Bootstrap.js Changed Development

By using these functions, developers could manually inject their code and user interface elements into the browser when the add-on was enabled, and clean them up when it was disabled. This meant users could install and use extensions immediately without losing their open tabs to a browser restart.

However, bootstrap.js had a downside. While it removed the restart requirement, it forced developers to manually write the cleanup code. If a developer forgot to remove an event listener or UI element during the shutdown() phase, it caused memory leaks and browser instability. Furthermore, bootstrapped add-ons still had direct, unrestricted access to XPCOM, meaning they could still easily break when Firefox updated.

The Jetpack Project and the Add-on SDK

Running parallel to the introduction of bootstrap.js was Mozilla’s Jetpack project, which culminated in the release of the Add-on SDK. Mozilla recognized that even with bootstrap.js, writing extensions was still too difficult and prone to errors.

The Jetpack Add-on SDK was designed to solve both the restart problem and the complexity problem simultaneously.

Key Features of the Add-on SDK

  • Web Standards: Developers could build extensions using familiar HTML, CSS, and JavaScript, completely avoiding XUL and XPCOM.
  • Restartless by Default: Under the hood, the SDK used the bootstrap.js mechanism, automatically handling the startup() and shutdown() cleanup processes so developers did not have to worry about memory leaks.
  • Modular APIs: Based on the CommonJS specification, the SDK provided high-level, stable APIs for common tasks, such as creating toolbar buttons, managing tabs, or modifying web pages (using scripts like page-mod).
  • Security and Stability: By abstracting the browser's internals behind specific SDK APIs, Mozilla could change the underlying code of Firefox without breaking the add-ons that used the SDK.

Developers used command-line tools—originally cfx and later the Node.js-based jpm—to package and test their SDK add-ons.

The Demise of Bootstrap.js and Jetpack

While bootstrap.js and the Jetpack Add-on SDK were massive improvements over traditional XUL extensions, they were ultimately transitional technologies.

In the mid-2010s, Mozilla began overhauling Firefox to use a multi-process architecture known as Electrolysis (e10s), which separated the browser's user interface from the web content processes to improve security and performance.

Bootstrap.js add-ons, and even some Jetpack SDK add-ons that bypassed standard APIs to access low-level browser internals, struggled to function in a multi-process environment. They relied on synchronous communication between the UI and web content, which caused severe browser lag under the new architecture.

To fully modernize Firefox and achieve compatibility with the broader browser ecosystem, Mozilla deprecated XUL, bootstrap.js, and the Jetpack Add-on SDK. With the release of Firefox 57 (Firefox Quantum) in November 2017, Mozilla disabled support for all legacy extensions, transitioning exclusively to the WebExtensions API—a cross-browser system originally pioneered by Google Chrome.