Add-on Compatibility for Firefox 53

If you haven’t yet, please read our roadmap to Firefox 57. Firefox 53 is an important milestone, when we will stop accepting new legacy add-ons on AMO, will turn Multiprocess Firefox on by default, and will be restricting binary access from add-ons outside of the WebExtensions API.

Firefox 53 will be released on April 18th. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 53 for Developers, so you should also give it a look.

General

Password Manager

The 3 following changes are related, and the main impact is that add-ons can no longer call findSlotByName("") to figure out if the master password is set. You can find an example on how to change this here.

XPCOM and Modules

WebExtensions

  • Encrypt record deletes. The storage.sync API hasn’t shipped yet, but it’s probably already in use by some pre-release users. This change causes old synced data to be lost.

Let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 53, I’d like to know.

The automatic compatibility validation and upgrade for add-ons on AMO will happen in a few weeks, so keep an eye on your email if you have an add-on listed on our site with its compatibility set to Firefox 52.

20 responses

Post a comment

  1. Kohei Yoshino wrote on :

    element has not been removed yet.

    Reply

    1. Kohei Yoshino wrote on :

      I meant applet element…

      Reply

      1. Jorge Villalobos wrote on :

        Okay, thanks, I thought this would land in 53.

        Reply

  2. Yan Yu wrote on :

    Hi,

    Is there a limit of number of add-ons you can create ?

    Thanks.

    Reply

    1. Jorge Villalobos wrote on :

      There’s no limit, no.

      Reply

  3. golf wrote on :

    >we will stop accepting new legacy add-ons on AMO

    Will it be possible to sign, self-host and distribute new unlisted legacy add-ons from April 18th (FF53) to November 14th (FF57)?

    Will it be possible to sign, self-host and distribute new unlisted WebExtensions add-ons after November 14th (FF57)? Do you have any plans on changing signing procedure/rules/policies for WebExtensions before or after November 14th (FF57)? In the future will it still be as easy as it is now to sign WebExtensions add-on?

    Reply

    1. Jorge Villalobos wrote on :

      > Will it be possible to sign, self-host and distribute new unlisted legacy add-ons from April 18th (FF53) to November 14th (FF57)?

      You won’t be able to create new ones, only update existing ones.

      > Will it be possible to sign, self-host and distribute new unlisted WebExtensions add-ons after November 14th (FF57)?

      Yes.

      > Do you have any plans on changing signing procedure/rules/policies for WebExtensions before or after November 14th (FF57)? In the future will it still be as easy as it is now to sign WebExtensions add-on?

      We have no plans to change our support for unlisted add-ons in the future.

      Reply

      1. golf wrote on :

        >You won’t be able to create new ones, only update existing ones.

        Are you sure? I won’t be able to SIGN new UNLISTED legacy extensions after April 18th (FF53)? Do you mean I’ll have to reserve IDs NOW in case I want to create new UNLISTED legacy extensions after April 18th (FF53)?

        Reply

        1. Jorge Villalobos wrote on :

          That’s the current plan, yes.

          Reply

          1. golf wrote on :

            But in the other comment (https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/comment-page-2/#comment-223685) you said:

            >For listed versions, once you switch to WebExtensions, you can’t go back to legacy.

            meaning that for UNLISTED versions, I can go back to legacy. That means after April 18th (FF53) I can SIGN a new UNLISTED WebExtensions extension and update it to SIGNED UNLISTED LEGACY extension.
            So in order to SIGN a new UNLISTED LEGACY extension after April 18th (FF53) I will have to SIGN a new UNLISTED WebExtensions extension and then make it LEGACY, right?

          2. Jorge Villalobos wrote on :

            After 53 you can update any existing listing, legacy or not, with either listed or unlisted versions. If your listed versions are already WebExtensions, then you can’t submit legacy updates there. Unlisted updates can be legacy or WebExtensions, in any order.

            When I say new add-ons, I mean completely new listings with new add-on IDs.

  4. Leslie wrote on :

    Firefox 52 ESR is published yesterday. It seems that extension signing is not mandatory in ESR channel and e10s can be disabled by add-ons.
    I want to confirm the extension signing policy in ESR channel coz it should be mandatory from Firefox 48(https://wiki.mozilla.org/Add-ons/Extension_Signing) and when e10s cannot be disabled.

    Reply

    1. Jorge Villalobos wrote on :

      Signing should be enforced by default on ESR, but there’s a preference that allows you to disable it. e10s can be disabled by add-ons, at least up to 53, but possibly all the way up to 57.

      Reply

      1. Leslie wrote on :

        Yeah, I set xpinstall.signatures.required to false in my extension. This preference works well on ESR but seems obsolete on normal Firefox
        So I wonder when this preference will be obsolete in ESR.

        Reply

        1. Jorge Villalobos wrote on :

          There’s no plan of removing that preference in ESR.

          Reply

  5. Jerry Cook wrote on :

    Why has MyBookmarks stopped working?

    We just discovered this wonderful visual rep of our many bookmarks need for our job. No it doesn’t work.

    How do we fix it?

    Reply

    1. Jorge Villalobos wrote on :

      Which add-on are you referring to? Do you have a link?

      Reply

      1. Matt wrote on :

        Wonderful addon, not working 🙁
        https://addons.mozilla.org/fr/firefox/addon/mybookmarks/

        Reply

        1. Jorge Villalobos wrote on :

          Looks like it should be fixed now.

          Reply

          1. Matt wrote on :

            it works now. Thank you.

Post Your Comment