Add-on Compatibility for Firefox 54

Apr 5 2017

If you haven’t yet, please read our roadmap to Firefox 57.

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

General

Remove -moz-appearance. This doesn’t apply to CSS sheets loaded using a chrome:// URL, but it does affect inline CSS styles in XUL and JavaScript code.

XPCOM and Modules

Remove nsIFormHistory2.
Don’t allow empty host name for URLTYPE_AUTHORITY URLs. This affects add-ons that use nsIContentPolicy to redirect certain requests (a practice that isn’t recommended, but some add-ons are known to use it).
Remove token arguments from nsIX509CertDB.importPKCS12File and exportPKCS12File.

WebExtensions

Update: sessions.restore returns an array instead of an object. The return value is now an object, matching what the equivalent Chrome API does.
Implement runtime.onMessageExternal/onConnectExternal. Quoting comment 34, this changes the meaning of the browser.runtime.id property, which may cause issues for extensions which expect that to be the same as the ID used in their URLs.
webRequest doesn’t check host permissions. You’ll need to add the necessary permissions for webRequest to continue working. At the moment this is incompatible with the Chrome API.

Let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 54, 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 53.

9 responses

Kees wrote on April 5, 2017 at 1:16 pm:

Is the WebExtension feature set of this version already on a proper level (i.e. a level where the features of the top 25 [and preferably the top 50-100] most popular add-ons are implemented *with version 54*)??? If it is not then I strongly suggest/recommend/ask for a change in plan related to deprecating the XPCOM based add-ons.

In that case I (again) suggest to extend the support of XPCOM based add-ons to at least the next ESR (It is still *VERY* surprising that a major change like this one is not aligned to be effective just after an ESR edition) .

N.B. Is it possible to explain *why* a major change like this is not aligned to be just after an ESR version? As that is a much more sensible version than doing it about 3 months before the next ESR….
1. Jorge Villalobos wrote on April 5, 2017 at 1:31 pm:
  
  You can find the current plan on this blog post. We don’t intend to change it, and there’s plenty of discussion around it in the comments.
  1. Kees wrote on April 5, 2017 at 1:41 pm:
    
    I know of this plan, however this still doesn’t address the question why it is not aligned to be after an ESR…
    
    And it also doesn’t answer the question related to the feature-parity.
    
    When the feature set of WebExtensions is not the same as the top 25 most popular XPCOM add-ons then there is a major regression related to add-ons which isn’t a logical action in a version just before the next ESR.
    1. Jorge Villalobos wrote on April 5, 2017 at 1:48 pm:
      
      Quick summary of what’s already been discussed on that post and the comments:
      
      1) Starting with 57, many things will break that will also break add-ons. Most add-ons that aren’t WebExtensions will be broken regardless. Aligning with ESR is not a goal.
      2) WebExtensions will never do everything XPCOM does, so feature parity is not a goal. Some top add-ons can’t be completely ported (DownThemAll and Firebug come to mind) and we’re accepting that risk.
      1. Arnaud wrote on April 6, 2017 at 3:15 am:
        
        Hello Jorge,
        
        I don’t want to troll (and you don’t need to waste time answering me), but I wouldn’t call the second item a “risk”. It’s more of a regression. The risk are : bad buzz (already there), unhappy users and loss of market share.
        
        Don’t get me wrong, I love WebExtensions and I want Firefox to improve quickly. I understand that sometime you need to make sacrifices (in french we say “lâcher du lest”, literaly “to dump ballast”, it’s an hot-air ballon analogy). But it looks like communication on this subject is far from perfect.
      2. kup wrote on April 7, 2017 at 9:32 am:
        
        Interesting words: “we’re accepting that risk”. Are you trying to convince or to soothe yourselves? WebExtensions is a path to nowhere, but Mozilla is too blind to see it. I know that my words change nothing, but, at last, stop telling lies to community, guys. Please.
Juraj M. wrote on April 11, 2017 at 4:33 am:

@kup I understand your frustration – spending so much time learning some API that is now gonna be obsolete. But now there will be a common standard that allows you to port your extension to all popular browsers including Edge with minimum or zero effort.
1. Leif wrote on April 29, 2017 at 2:49 am:
  
  While it is true that in a general sense, programming an extension is a bit easier with the WebExtensions, it is not entirely true, or honest, to say that all web extensions will be easily portable. It’s only the beginning of the API’s life cycle, yet there are already incompatibilities creeping into the various platforms’ implementations in response to the very different needs, attitudes and philosophies of each developer community. Who’s to say what the situation will look like in another year or two. And it’s disingenuous to imply that ease of portability of an add-on that looks like every other add-on and can’t do anything interesting that add-ons are historically known for doing equates to a benefit that outweighs the sacrifices. Who cares if I can easily write and port an add-on, if users can easily live without it because it provides a negligible benefit to them due to loss of power, accessibility or usability when compared to the functionality of XPCOM/XUL? Those technologies I can let go of. Switching APIs a lot is annoying as heck, but I can move past that. The thing that is unforgivable is removing power from the developer and the end users, and telling us it is an improvement. Those are simply lies based on the collective delusion of developers being unduly influenced by corporate interests which seem to infest the standards bodies and dictate the terms of reduced quality, and make a point of telling us that our needs do not matter and that we shall be ignored.
Leif wrote on April 29, 2017 at 3:24 am:

Regarding -moz-appearance, I do not feel the statement is entirely correct. “This doesn’t apply to CSS sheets loaded using a chrome:// URL, but it does affect inline CSS styles in XUL and JavaScript code.” The automated validation will send false-positive warnings about using -moz-appearance even from a chrome:// URL, which may cause confusion and potentially delay the review process. The developers of the validator shrug it off as “too hard” to try to be “too intelligent” handle “specific cases” like this, and so they generally have refused any request to patch the validator. They brush it off as “a false positive you should just ignore, because there’s so many false positives anyways…”. I hold the position that a validator which does not clearly communicate a state of validity is fundamentally broken, and that any excuse saying it’s “too hard” to do things properly is invalid. — But beyond the validator, the statement is also incorrect in that use of -moz-appearance from chrome:// in v54 or v55 will still work. For my use case, it did not work, and so I needed to add an “appearance” to my CSS. My use case was for a XUL menu with class menu-iconic and top-level menu-items set to menuitem-iconic, to allow icons to be used at the top level, but with a sub-menu’s menu-items with class menuitem-non-iconic, to allow text-only. This creates a situation where there is no icon, and the text aligns with the left edge of the menu, but there still remains a translucent vertical bar that was used to separate the icon from the text. The only way to get rid of that is to set “-moz-appearance: none” (for Firefox v29.0-53.*). With -moz-appearance removed, the vertical separator returns, so that “appearance: none” must also be used to support Firefox v54-56. — And this highlights another area of stupidity of the Mozilla plan echoed in the sentiments about ESR support. The world doesn’t upgrade all at once, certainly not because you or I develop a new shiny toy to play with. Some people as individuals simply update every few years. It’s not our job to harass them or deny them access to services (i.e. those provided by add-ons) because they aren’t ready to upgrade. There’s a matter of respecting the user’s personal choice and freedom and autonomy to not update right away. Other users may not have any personal choice in the matter, as update schedules in larger organizations come at increased management costs, and for any number of obscure reasons (i.e. browser compatibility with some legacy system that is mission critical and can’t afford to re-develop from scratch). Likewise we shouldn’t be discriminating against them and ceasing all development support by not allowing add-on developers to continue to maintain any add-ons for such users. This -moz-appearance validation issue is just one example of how it starts, how the attitude that “our developer’s needs don’t matter” translates into “we don’t care if you can validate” and we’re going down a slippery slope “we don’t care if you can continue to support your users”. You know, Mozilla, it’s a two way street, and users can just as easily say, “we don’t care about you anymore (uninstall)”. The only thing “good” about WebExtensions, from a PR perspective, is damage control. So developers or users want to walk away, but now where can they go to get a new and interesting feature? All browsers use the same castrated API, so it can’t be escaped. It’s stifling, it’s suffocating, it’s trapping and enslaving the end user, holding them hostage as Mozilla makes one bad decision after another, without hesitation or remorse, and absolutely no concern for what developers and users actually want. They’re only listening to the corporations which only care about flooding the market with useless (and often sketchy) add-ons that can be easily monetized to unsuspecting end-users who just frankly don’t know any better.