Update: this post was updated to reflect a change in how we determine when Firefox will run in multiprocess mode. Firefox won’t run in multiprocess mode unless add-ons are explicitly declared to be compatible with Multiprocess Firefox. Compatibility shims will be removed earlier than indicated in the previous version of this post.

Update 2: we can now confirm that this plan also applies to Firefox for Android.

Back in November, we laid out our plans for add-ons in 2017. Notably, we defined Firefox 57 as the first release where only WebExtensions will be supported. In parallel, the deployment of Multiprocess Firefox (also known as e10s) continues, with many users already benefiting from the performance and stability gains. There is a lot going on and we want you to know what to expect, so here is an update on the upcoming compatibility milestones.

We’ve been working on setting out a simple path forward, minimizing the compatibility hurdles along the way, so you can focus on migrating your add-ons to WebExtensions.

Legacy add-ons

By legacy add-ons, we’re referring to:

All extensions that aren’t WebExtensions. Specifically: XUL overlay extensions, bootstrapped extensions, SDK extensions, and Embedded WebExtensions.

Complete themes. These add-ons shouldn’t have problems with multiprocess compatibility but will follow the same compatibility milestones as other legacy add-ons. We will provide more details on what’s coming for themes very soon in this blog.

Language packs, dictionaries, OpenSearch providers, lightweight themes, and add-ons that only support Thunderbird or SeaMonkey aren’t considered legacy.

Firefox 53, April 18th release

Firefox will run in multiprocess mode by default for all users, with some exceptions. If your add-on has the multiprocessCompatible flag set to false, Firefox will run in single process mode if the add-on is enabled.

Add-ons that are reported and confirmed as incompatible with Multiprocess Firefox (and don’t have the flag set to false) will be marked as incompatible and disabled in Firefox.

Unless your add-on has the multiprocessCompatible flag set to true or is a WebExtension, Firefox will run in single process mode. Firefox will run in multiprocess mode if all enabled add-ons meet this criteria.

Add-ons will only be able to load binaries using the Native Messaging API.

No new legacy add-ons will be accepted on addons.mozilla.org (AMO). Updates to existing legacy add-ons will still be accepted.

Firefox 54-56

Legacy add-ons that work with Multiprocess Firefox in 53 may still run into compatibility issues due to followup work: Multiple content processes is being launched in Firefox 55. This enables multiple content processes, instead of the single content process currently used. Sandboxing will be launched in Firefox 54. Additional security restrictions will prevent certain forms of file access from content processes.

Multiprocess compatibility shims are removed from Firefox, starting with the Nightly and Developer Edition channels.

Firefox 57, November 14th release

Firefox will only run WebExtensions.

AMO will continue to support listing and updating legacy add-ons after the release of 57 in order to have an easier transition. The exact cut-off time for this support hasn’t been determined yet.

Multiprocess compatibility shims are removed from Firefox. This doesn’t affect WebExtensions, but it’s one of the reasons went with this timeline.

For all milestones, keep in mind that Firefox is released using a “train” model, where Beta, Developer Edition, and Nightly correspond to the future 3 releases. You should expect users of pre-release versions to be impacted by these changes earlier than their final release dates. The Release Calendar lists future release dates per channel.

We are committed to this timeline, and will work hard to make it happen. We urge all developers to look into WebExtensions and port their add-ons as soon as possible. If you think your add-on can’t be ported due to missing APIs, here’s how you can let us know.