Add-on Compatibility for Firefox 53

Feb 28 2017

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

Remove support for multi-package xpis. This is still used by a few add-ons that mix complete themes and extensions in a single package, but it’s going away along with other legacy add-on technologies.
Use a separate content process for file:// URLs. This slightly changes the behavior of _openURIInNewTab.
Remove support for -moz-calc().
dom-storage2-changed notifications are not useful for private windows. This created a separate dom-private-storage2-changed notification for private windows.
Remove unused bindings from urlbarbindings.xml. Removes <splitmenu> and <menuitem-tooltip>.
Move content vs. content-primary distinction out of the type browser attribute. This means type="content-primary" now works exactly as type="content", and will be dropped eventually.
MimeTypeArray should have unenumerable named properties.
PluginArray and Plugin should have unenumerable own properties.

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

Don’t expose the NSS certificate nickname API in PSM interfaces. This changes a number of methods in nsIX509Cert: addCert, addCertFromBase64, findCertByNickname, findEmailEncryptionCert, findEmailSigningCert.
AddonManager APIs should try to support both callbacks and promises. This makes the callback for getInstallForURL to be called asynchronously.
Remove getURIForKeyword API. PlacesUtils.keywords.fetch should be used instead.
Support ServoStyleSheets in nsIStyleSheetService::PreloadSheet. This changes the return type of preloadSheet, which shouldn’t affect you unless you do anything other than pass it to addSheet.

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

Kohei Yoshino wrote on March 1, 2017 at 6:44 am:

element has not been removed yet.
1. Kohei Yoshino wrote on March 1, 2017 at 6:45 am :
  
  I meant applet element…
  1. Jorge Villalobos wrote on March 1, 2017 at 6:48 am:
    
    Okay, thanks, I thought this would land in 53.
Yan Yu wrote on March 2, 2017 at 8:00 pm:

Hi,

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

Thanks.
1. Jorge Villalobos wrote on March 3, 2017 at 8:25 am:
  
  There’s no limit, no.
golf wrote on March 6, 2017 at 7:04 am:

>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?
1. Jorge Villalobos wrote on March 6, 2017 at 8:27 am:
  
  > 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.
  1. golf wrote on March 6, 2017 at 12:54 pm:
    
    >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)?
    1. Jorge Villalobos wrote on March 6, 2017 at 2:42 pm:
      
      That’s the current plan, yes.
      1. golf wrote on March 7, 2017 at 9:49 am:
        
        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 March 7, 2017 at 12:20 pm:
        
        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.
Leslie wrote on March 7, 2017 at 7:43 pm:

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.
1. Jorge Villalobos wrote on March 8, 2017 at 12:45 pm:
  
  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.
  1. Leslie wrote on March 8, 2017 at 9:03 pm:
    
    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.
    1. Jorge Villalobos wrote on March 9, 2017 at 9:33 am:
      
      There’s no plan of removing that preference in ESR.
Jerry Cook wrote on March 8, 2017 at 6:27 am:

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?
1. Jorge Villalobos wrote on March 8, 2017 at 12:45 pm:
  
  Which add-on are you referring to? Do you have a link?
  1. Matt wrote on March 11, 2017 at 3:45 am:
    
    Wonderful addon, not working 🙁
    https://addons.mozilla.org/fr/firefox/addon/mybookmarks/
    1. Jorge Villalobos wrote on March 13, 2017 at 8:30 am:
      
      Looks like it should be fixed now.
      1. Matt wrote on March 16, 2017 at 11:27 am:
        
        it works now. Thank you.