Add-ons/Future of Bootstrap

What

Third party add-ons can only be a WebExtension. However "internal" Mozilla add-ons can be bootstrapped with special signing. We intend to remove bootstrapped add-ons completely from the Firefox ecosystem.

See Internal Signing for information on this internal signing process.

Why

Bootstrapped add-ons represent use of a legacy technology. The tools and paths are becoming increasingly deprecated and broken. Bootstrapped add-ons can easily be broken every release and make updating Firefox harder.

Mozilla should use, as much as possible, the same tools as everyone else. This will drive WebExtensions forward for third party and internal consumers.

How

Working with the teams that have bootstrapped add-ons we'll do one of the following, depending upon what makes the most sense:

• Move the custom code into Firefox.
• Move the custom code into a WebExtension Experiment bundled with the WebExtension 1364976.
• Move the custom code into Firefox as a WebExtension API.
• Move the custom code into Firefox as a WebExtension API available only to Mozilla 1280235.

A working group has been established to work on this and we'll be sending out some documentation and plans shortly.

Notes

The future of bootstrapped addons

With the deprecation of legacy extensions in Firefox 57, we have eliminated most uses of bootstrapped extensions in Firefox. System add-ons and other special cases such as Shield extensions can still be written as bootstrapped extensions. In the near term, we hope to make it possible for these extensions to be written as WebExtensions (with things that aren't suitable for public WebExtension APIs accessed through private APIs or WebExtension experiments). But in the mean time, other changes in Firefox have the potential to break bootstrapped extensions. This page is meant to document some of the problems that authors of bootstrapped extensions should be aware of.

• Tightened content process sandbox: The sandbox for web content processes now prevents these processes from reading from the filesystem outside of the profile. As a result, if you use temporary installation (i.e., the "Load Temporary Add-on" button in about:debugging) and your extension loads anything from a resource: URL in a content process, this will break. Possible workarounds include relaxing the sandboxing restrictions by setting the "security.sandbox.content.level" preference, installing the extension into the profile during development, or restructuring the extension to communicate with content processes via message managers.

• Changes to internal interfaces: We previously took care not to change XPCOM interfaces that might be used by extensions. With extension no longer able to access Components directly, internal interfaces may change at any time. If your extension is not covered by tests that run in automation, be aware that it may be broken by internal changes at any time. Similarly, there is an active effort to remove XBL bindings, an extension that uses XUL+XBL is at risk of having XBL bindings disappear at any moment.