Mozilla Add-ons Community Blog
Add-ons logo
Categories: compatibility developers documentation

Add-on Compatibility for Firefox 56

24 responses

Firefox 56 will be released on September 26th. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 56 for Developers, so you should also give it a look. Also, if you haven’t yet, please read our roadmap to Firefox 57.

Compatibility changes

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

The automatic compatibility validation and upgrade for add-ons on AMO will run 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 55.

Last stop!

LEGO end of train line

Firefox 56 will be the last version of Firefox to support legacy add-ons. It’s the last release cycle you’ll have to port your add-ons to WebExtensions. Many planned APIs won’t make the cut for 57, so make sure that you plan your development timeline accordingly.

This is also the last compatibility overview I’ll write. I started writing these 7 years ago, the first one covering Firefox 4. Looking ahead, backwards-incompatible changes in WebExtensions APIs should be rare. When and if they occur, we’ll post one-offs about them, so please keep following this blog for updates.

24 comments on “Add-on Compatibility for Firefox 56”

  1. erosman wrote on

    Thank you Jorge for 7 years of hard work.

    1. Jorge Villalobos wrote on

      Thanks!

    2. Andreas wrote on

      Agreed, thank you for these blog posts!

  2. Stefan wrote on

    And is the Firefox v56 speed improved for the extension? Because when I use my Turn Off the Lights Firefox extension (that is converted to the WebExtensions ) it is very slow. While in Google Chrome and Opera is fast and stable.
    https://addons.mozilla.org/en-US/firefox/addon/turn-off-the-lights/

    1. Jorge Villalobos wrote on

      I know there’s a lot of work going on in the performance side of things, but you should file a bug if there’s something in particular we should be looking into.

  3. Kees wrote on

    “Many planned APIs won’t make the cut for 57, so make sure that you plan your development timeline accordingly.”
    Does this mean that there are a number of features who should be available will not be available in Firefox 57? Somehow this doesn’t look like a good planing related to the feature set…

    Is Mozilla considering alternative plans to ensure that users will not get non-working add-ons for a few months and then suddenly they are available again (because of the API which was not available in Firefox 57, but is in Firefox 62…) – either by delaying the removal of the legacy extensions for a few versions or by creating a special longer supported version based on Firefox 56 for example.

    Is nobody at Mozilla concerned about having an incomplete API in WebExtensions? Why didn’t Mozilla invest *much*, *MUCH* more in WebExtension developments in case Firefox 57 should be the last version where the versatile XUL-based add-ons can be used?

    (The picture is showing the end of a rail-road but to me the way Mozilla is handling the switch-over is more like building a bridge (i.e. WebExtensions) to ensure that the release train can safely reach the other side of a ravine. However the bridge is far from complete, instead of slowing down on the plan to disable XUL/XPCOM-based extensions [moving the ravine into the future so to speak] or doubling the efforts to get a proper bridge [much better WE implementions where the API’s are there and not going with “many API’s will not make the cut”] all that is done is still planning to disable the versatile XUL/XPCOM extensions as we have decided that we have to land features which require this in the Fx 57 time-line… Changing this to Fx 58,59 isn’t even considered it seems).

    1. Jorge Villalobos wrote on

      The development of the API had a couple of goals: parity with the main APIs that Chrome supports, and a number of additional APIs to support popular Firefox add-ons. The plan towards 57 is expected to meet those goals.

      But, there’s more to do after 57. Developers have been proposing new APIs, or have been putting their support behind lower-priority APIs, so I’m trying to set expectations. The WebExtensions API will never be “complete”. It will just evolve with time. What matters now is that developers know what will make it to 57 and what won’t, so they know what to do about their add-ons.

      57 is a hard deadline. Many other things are changing in Firefox that would break legacy add-ons anyway. We expect most popular add-ons to make the cut, and are in constant communication with the developers to make sure that’s still on track.

    2. Ulf3000 wrote on

      just download nightly , itll support most xul and sdk addons for at least a from now on a year or longer even

  4. Joe wrote on

    So basically from FF57 release, AMO size reduces from 24,178 to 3,358 add-ons? If this is logical I am not following. I am just thinking how much time is wasted on writing 24,178 add-ons.

    3,358 -> https://addons.mozilla.org/en-US/firefox/tag/firefox57
    24,178 -> https://addons.mozilla.org/en-US/firefox/search/?q=&appver=&platform=

    Still there any many things WebExtension cannot handle like access to the password manager or file API for instance. There is literally no way to make many extensions compatible with FF57 at this point. I know you guys are working hard on the WebExtension development, but still, your timing is so wrong. Just keep the old add-on compatible until you reach the point that it is possible to port most add-ons.

    Anyway, thanks Jorge for the 7 years. It is time for me to move on.

    1. Jorge Villalobos wrote on

      A sizeable chunk of those 24K add-ons don’t work in current versions of Firefox. We just don’t have a clear view of how many because of the complicated compatibility story that we’ve had with them. And we expect those 3K to grow significantly in the months to come :).

      For sure, there are add-ons that won’t be implemented using WebExtensions, either because it’s not possible with the new API or because the developer decides the effort isn’t worth it. I think the main issue has more to do with the paradigm shift into a restricted API rather than timing, and there will never be an ideal time for this kind of move.

      1. Ulf3000 wrote on

        i could myself easily find 300 ultra legacy (means they didn´t work for years)addons per day , a team of 10 people could easily have cleaned the data base in less than a month , all i here from you guys is excuses and talk-arounds

  5. Athena82 wrote on

    Thank you Jorge for all your blog posts!
    It was nice to have someone from Mozilla answering questions from the community in an unambiguous and clear way. Very much appreciated!

    1. Jorge Villalobos wrote on

      Thank you!

  6. erosman wrote on

    On testing FF56, I noticed that it will disable all non-Multi-process Compatible addons which includes many of the popular addons.

    It is worth noting.

    1. Ulf3000 wrote on

      for most of those addons , just open them in winrar and add the multiprocessing flags to install.rdf and package.json

  7. john wrote on

    yes thank you jorge i know ive been a thorn in the side sometimes but YOU are the only person who actually answers questions and cares about your firefox people unfortunatly not one of my 13 addons work anymore lol so unless firefox brings them back mostly the sports addons i cant use it i actually went back to firefox 3.5 lol and my sports scores 365 works just great so i just use it for that

    1. Jorge Villalobos wrote on

      If you want to stick with an older version of Firefox for longer, I suggest that you at least try the ESR version, which should support legacy add-ons at least for another year, and gets security updates.

      1. john wrote on

        its fine jorge because its firefox 3.5 i just have the status bar showing on my desktop for the scores nothing else i dont use it at all for browsing you can re size that version to just have the status bar showing for all my scores its just too bad the developer of that addon doesnt like the new firefoxes and i dont blame him the new firefoxes are ram and cpu killers why is that

  8. custom.firefox.lady wrote on

    Got the compatibility with fx56 email saying my add-on Stay-Open Menu (https://addons.mozilla.org/firefox/addon/stay-open-menu/) was found to be compatible. But it’s not. It will (partially) work if you disable/re-enable it after every fx restart. Will become Nightly-only at fx 57 anyway, so it’s not likely to get fixed for 56. I changed the compatibility info back to 55 on AMO, but that doesn’t seem to have much effect. Sad to see the end of xul add-ons, but best wishes to you anyway. Thanks for your helpfulness in these blog posts.

    1. Jorge Villalobos wrote on

      I marked it as incompatible with 56 and above, thanks.

  9. DAve Shillito wrote on

    Is there a way for a user to determine in advance which addins Firefox 57 will break?

    For me many addins are the reason I use Firefox, but I know that some will not be updated, either since the developer is no longer supporting them, or because the update would take too much effort. However they currently work fine.

    For example I’m pretty sure this is the case for
    Classic Theme Restorer
    Tree Style Tab
    Tab Kit 2nd Edition
    and it would be useful to know which of the other 30 odd addins I use may stop working to determine if I want to take Firefox 57 or switch to the ESR.

    1. Jorge Villalobos wrote on

      The Add-ons Manager will eventually indicate which add-ons you have installed are legacy. I can see it on the Firefox 55 Beta, so it should make it to release soon. Alternatively, you can go to their listing pages on AMO (if they have one), and look for a green tag next to their name that says “Compatible with Firefox 57+”.

      1. DAve Shillito wrote on

        Thanks, I will await that change.

  10. Dimitre wrote on

    It is a shame because Webextensions still has no support to context menu selectors, so it will be a leap backwards.