The Road to Firefox 57 – Compatibility Milestones

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:

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.
  • 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.

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.

42 responses

Post a comment

  1. Kees wrote on :

    I’m a bit puzzled about what Mozilla is trying to do. First there is much work on getting the classic add-ons running with multi-process Firefox and when this is more or less stable then suddenly WebExtensions are announced. WebExtenstions is fine, however de-supporting the classic add-ons less then 2 years after WebExtensions is announce is wrong. In my opinion the classic add-ons should still be supported for another 2 years*. Please take into consideration the work add-on developers already have done to get there classic add-ons working, give them significant time to switch to WebExtensions.

    In the mean time there should be a clear effort to get EVERYTHING (or at least 80-90%) of the feature set from classic add-ons working as a WebExtensions. (That means that No-Script, GreaseMonkey, Tab Groups should all work as an WebExtension). The 2 year path* (instead of 6 months), should be sufficient for add-on developers to migrate to WebExtensions is a natural way.

    At the moment is seems that add-on developers have to rush to get their extensions converted, which of course is never a good idea.

    *: Ideally this would be even longer, long time support would be 3-5 years IMHO.

    One comment about: “If you think your add-on can’t be ported due to missing APIs, here’s how you can let us know.” – This is ridiculous of course, based on the add-ons alreadt hosted at addons.mozilla.org the Mozilla engineers are able to determine this themselves. The/all features used by these classic add-ons should be in WebExtensions before any disabling of the legacy XUL-based add-ons is done. (When then there are still options missing the developer of the non-AMO add-on can indeed indicate to Mozilla what is still missing).

    Reply

    1. alex wrote on :

      “…based on the add-ons alreadt hosted at addons.mozilla.org the Mozilla engineers are able to determine this themselves.”

      Given the dynamic nature of JavaScript, doing this would probably be equivalent to solving the halting problem.

      Reply

      1. Kees wrote on :

        > Given the dynamic nature of JavaScript, doing this would probably be equivalent to solving the halting problem.

        Actually XPCOM isn’t that dynamic. It may be huge (as in theory a classic add-on can use all XPCOM components available). I’m not saying it is easy, but technically is can be done. Even an analysis (using every possible tool, even grep would do) of the top 10 most popular extensions will help a lot. (Although as indicated elsewhere the next step would be to check the top 100 extensions of course).

        Reply

    2. kjemmo wrote on :

      I agree a lot in this comment.

      We have been encouraged to port to WebExtensions for some time now, but the truth is that for many developers it is still impossible due to missing APIs.

      I recently asked when a toolbar API will be available and so far no one has been able to give me a clear answer. Or the clear answer is “no one really knows” it might or it might not be available and no one knows when.

      I guess the answer is the same for several other APIs that are needed to port legacy extensions.

      Is incredibly frustrating with all this uncertainty.

      Reply

    3. Termy wrote on :

      according to the developer of some of my favorite addons ( chrome://thefoxonlybetter/content/lastnotice.html ), i fully agree with you.

      I’m shocked that Mozilla is letting down/abandon one of the main reasons FF is loved and that sets FF appart from all the other browsers – most powerfull add-on options.
      I’m sure there’s a reason to switch to WebEx, but then WebEx should be feature-competitive to the “old” APIs and not missing so much that many addons can’t be ported over…

      Reply

    4. Jorge Villalobos wrote on :

      > WebExtenstions is fine, however de-supporting the classic add-ons less then 2 years after WebExtensions is announce is wrong.

      I fully admit the timing was bad. The opportunity and resources to launch WebExtensions came up when we were already into the initial e10s migration process, and the plans for Firefox also shifted in a way that WebExtensions can be the only path forward. We can’t support legacy add-ons for 2 years more because the APIs they rely on won’t exist then. Supporting them for longer only means extending the frustration of constant breakage, both for developers and users.

      > That means that No-Script, GreaseMonkey, Tab Groups should all work as an WebExtension

      NoScript will definitely be a WebExtension. I know the GreaseMonkey devs were looking into it, and there’s TamperMonkey which is a somewhat equivalent WebExtension. Don’t know about Tab Groups, though.

      > This is ridiculous of course, based on the add-ons alreadt hosted at addons.mozilla.org the Mozilla engineers are able to determine this themselves.

      Like someone else pointed out, this isn’t so trivial. We have tens of thousands of add-ons, some active and others abandoned, and the nature of the legacy platform means that there are no easily identifiable API points for most functionality. We have done some surveying and research, but hearing from developers who are still engaged in the process is the priority.

      Reply

      1. Kees wrote on :

        > I fully admit the timing was bad.

        At least this is acknowledged, however that doesn’t change the fact that Mozilla is able to ensure that even with this very bad timing the rest of the process is done in a way that add-on developers (and users) have sufficient time to make a change. Especially when timing of a big change is bad (because Mozilla is doing something which will effectively destroys hours and hours of work done by add-on developers) the organisation should be VERY generous in giving the developers time to adjust to the new add-on type. Even 2 years may be too fast, but a certain date has to be set. (I can understand the need for an extension type which also works on say Servo, but as long a the engine is Gecko there is no need to *rush* to the deprecation/removal of the classic add-ons without a sufficient transition period).

        > We can’t support legacy add-ons for 2 years more because the APIs they rely on won’t exist then. Supporting them for longer only means extending the frustration of constant breakage, both for developers and users.

        This seems a management decision and not a technical one, the APIs exist today and can continue to be supported. Of course any change should be done in a stable manner, which may not be easy – however they have worked for years and letting them work (maybe without Fx in e10s mode) for some more time gives the add-on developers sufficient time to switch over in a normal manner.

        Even if WebExtensions would implement about 90% of the features of classic add-ons (which as far as I know doesn’t), a transition of 6 months is way too fast. Now that the WebExtensions are still forming 6 months is just asking for big problems. How would a user react when add-ons are no longer working because this was done on purpose (by removing the classic add-on support)? The will never be happy. Even if this affects 5-10% of the Firefox users this is to much, and I read somewhere that about 40% of Fx users has an add-on installed. Say that only 15% is really using an add-on which will no longer work, what will that do related to publicity about Firefox???

        > I know the GreaseMonkey devs were looking into it, and there’s TamperMonkey which is a somewhat equivalent WebExtension. Don’t know about Tab Groups, though.

        From what I’ve read about TamperMonkey is that this is not as powerful as GreaseMonkey (comment made by somebody elsewhere on a Mozilla blog [yes I know this is a vague statement :-)]. About Tab Groups, I’ve got an announcement from the developer that he will not be able to convert this and among the reasons was that WebExtensions is just not complete enough for this. In addition the current maintainer writes about the work he has already done to get his add-ons working with Firefox/e10s: “Oh, by the way, I already did all that. It took me a year and a half of extensive rewritting to make my add-ons e10s/multiprocess compatible, something that is being rolled out only now, all with the prospect of a long-lasting life for them. And the WebExtensions announcement was made not two months after. “Demotivating” doesn’t quite cover it…”

        The only comment I can add to this, that is that just because the developers already have invested lots of time into getting their add-ons compatible with e10s Mozilla has a moral obligation to give them a large time-frame (the 2-5 year migration path I suggested would do). Even 2 years may be short for somebody who invested 1.5 years in e10s compatibility – where most of it is spare time as well. 6 months is just way too short…

        About the fact that Tab Groups is no longer working on Firefox in the future is even more insulting to the person who took over its development. As it was Mozilla people themselves who suggest that Tab Groups is further developed as an add-on, somebody is taking this responsibility and about 1 year later Mozilla says effectively “well, thanks for the work you did, but it was all for nothing…”. Especially this add-on developer should have received all the help in getting the add-on working on WebExtensions (including the implementation of the right APIs and help from Mozilla to get the add-on converted – maybe this would even be a good show-case how the transtion would be done).

        >>> This is ridiculous of course, based on the add-ons alreadt hosted at addons.mozilla.org the Mozilla engineers are able to determine this themselves.
        >Like someone else pointed out, this isn’t so trivial. We have tens of thousands of add-ons, some active and others abandoned, and the nature of the legacy platform means that there are no easily identifiable API points for most functionality.

        Well, I disagree with this (as this is not about JavaScript compatibility). As far as I know the core of the classic add-ons is based around XPCOM which in itself is fairly static technology. Even a simple grep in the 100-1000 most popular add-ons will give Mozilla engineers data to use. Instead of something relatively simple the burden is shifted to others (who did not necessary ask for this change). Of course there can be rough edges which will not materialize and for that input from developers will be helpful…

        After I placed the earlier comment I’ve browsed around a little and I did find the following overview (I know it is on a Wiki so not necessary up to date). https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Comparison_with_XUL_XPCOM_extensions#Privileged_APIs

        When about 60% of the XUL/XPCOM APIs are not yet available as a WebExtension API then the first focus has to be to get this working…

        Instead of rushing in changes which require disabling the classic add-ons the Mozilla engineers should be working on getting WebExtensions to a point where at least the functionality is provided which you already identified. The next step would be to ensure that the APIs used by the top 100 add-ons (based on usage) are implemented and when that is done the removal of the classic add-on infrastructure should be done.

        Also one other note: It seems that the deprecation of the classic add-ons is not even done on an ESR version, this seems really strange to me. A change as big as this one should IMHO only be done in a way where people get a long transition period which is provided by an ESR release, but it seems that even something simple as this is not taken into consideration.

        Reply

  2. Rockridge wrote on :

    It seems the release date of Firefox 57 is November 14th now. See RapidRelease/Calendar on MozillaWiki.

    Reply

    1. Jorge Villalobos wrote on :

      Thanks, it’s fixed now.

      Reply

  3. Eduard Braun wrote on :

    I hate how nobody at Mozilla ever even acknowledged “legacy developers”.
    If that’s really how important we are to you, then you’re going down with good reason!

    Reply

    1. John Stein wrote on :

      They took on the herculian task of implementing both multi-process and WebExtensions in parallel, because it was clear that both would require a lot of porting work for add-on developers and they wanted add-on developers to be able to go straight to the multi-process-compatible WebExtensions, therefore having to only port things once.

      They implemented those multi-process shims just to give add-on developers more time to port their extensions. They serve no other purpose and, as mentioned above, will be removed from the code base once this is done with.

      They got into contact with some of the high-profile add-on developers who had extensions that couldn’t be ported to WebExtensions to work out together how the new APIs should look like. The closing words of this blog entry are a link for you to do the same.

      And WebExtensions are even just being added to Firefox, because it’ll mean less fixing work for extension developers whenever changes are made to Firefox.

      I’ll allow you the opinion that you’d rather continue fixing up your extensions, even when they get started with Project Quantum, or that you just don’t think WebExtensions are sufficient to replace the current add-on ecosystem, but do not claim that Mozilla never even acknowledged legacy add-on developers.

      Reply

    2. Joe Mindel wrote on :

      @Eduard Braun, what makes you so special that you have to be catered-to on some deeply personal level, and that Firefox will “go down” because they are not doing do? Legacy is a big problem to Firefox, and speaking as someone who has made such addons in the past, I can fully understand why Firefox would need to move on. I don’t feel like I’m more important than Firefox, and that addons that refuse to cooperate in order to keep Firefox relevant are of any importance in the longer-run. Users don’t care as much as you think they do.

      Reply

    3. Jorge Villalobos wrote on :

      What do you think we should have done / be doing differently in terms of acknowledgement? We’ve been doing mass communications with developers for quite a while and are actually worried about being too spammy.

      Reply

      1. Eduard Braun wrote on :

        There are in fact multiple things that make me currently hate Mozilla (and I used to be a big fan of the organization creating the Browser I once loved). As the deprecation of XUL is only one part of many I’ll not limit myself to that but try to paint you the whole picture:

        – It started around the time “Australis” was implemented. To the current day I detest that change (as did many others, including many of the most avid addon-developers). It’ no coincidence “Classic Theme Restorer” is one of the most popular add-ons. Mozilla never acknowledged that Australis might not be a universally good idea. Instead it was forced upon people with some changes unnecessarily breaking existing functionality.
        – There were good things, too: Hardware rendering (with serious problems in the beginning though), support for HTML5 and native video decoding, so I had hope.
        – Around that time Mozilla also decided to cut out many settings and “streamline” about:preferences. Instead of just hiding those settings they were usually removed without replacement. To the current day I don’t know if those were political decisions at Mozilla (“we don’t like it so you can’t use it”) or if it’s – sorry the term – incompetence (“we wanted to change it but now we can’t maintain the previous implementation, whether you liked it or not”) but it made me seriously doubt the path Mozilla was taking.
        – With all that on the table Mozilla started to implement new “features” (e.g. the new newtab page complete with ads, a redesigned downloads window, Pocket, pdfjs, Firefox Hello, …) I assume I should have been delighted about – but I wasn’t… It were things I don’t need (and I doubt many other people wanted), often not within the scope of a webbrowser, and with every step it was getting harder and harder to disable the stuff I didn’t ask for and to not let Mozilla decide “what’s best for me”.
        – By then I had the impression Mozilla was piece-by-piece stripping out the parts of Firefox I liked and was replacing theme with stuff I didn’t need or want. I wasn’t happy but – with the help of add-ons and userchrome.css – I was always able to revert the changes Mozilla had done and return Firefox to a state in which it was useful for me.
        – At the time Mozilla announced e10s I was a bit happier again. Finally a change that wasn’t useless for me. I was motivated and brought my (XUL) add-ons up to speed to be compatible. It was a lot of work but i had the feeling it was the correct direction. I even got an AMO editor around that time as review queues were endless and I wanted to give back.
        – Then the big downer: Before e10s even was close to hit a stable version Mozilla announces to deprecate XUL add-ons?!? That was basically a punch in the face. I just had invested a lot of time into my addons and into reviewing and suddenly Mozilla decides: All that work you’ve done will be trashed in about a year or two! Even if this was paid work I’d been furious, but it wasn’t. Quite the opposite as I spent something very precious: my free time.
        – Now I’d hoped for Mozilla to really explain *why* this step was necessary (thoroughly as it – hopefully – was discussed in internal meetings) weighing the cons and the potential gains, preferably with somebody personally taking responsibility (I guess you’ve got managers who signed off on this long-term strategy?) and explaining why it in fact *is* the correct choice. I would have hoped that the fact that this change will destroy the work of hundreds of volunteer add-on developers would weigh enough to really try to sell why the change was worth that. Instead all the mass communications where more along the lines: “We – Mozilla – have decided it’s time to move on. Thanks for your efforts but if you want to stay compatible you have to rewrite your add-on”.
        – Personally I therefore got the impression Mozilla does not appreciate add-on developers very much. I got the feeling that the drag of add-on compatibility was seen as an annoyance for only a “small bonus” in functionality. I did not get the feeling that add-ons were being recognized as offering real and significant improvements upon the functionality Firefox offers natively and could considerably impact the usefulness of the overall browser. Along these lines it also feels a bit odd that I never read once in a statement from Mozilla that they were actually sorry for breaking compatibility! Instead announcements where always quite technical explaining from a top-down perspective what needs to be done to stay compatible without even considering the real-world implications this will have.
        – For me personally it’ll probably mean the end of my add-ons. I don’t have the time to do a complete rewrite. Also I doubt it would even be possible to port all of them to web extensions. (Before people jump in again that I should specify what i need: This alone needs an awful lot of time! How should I be able to specify what APIs I need off-hand? This would already require me to learn a lot about webextensions, potentially starting to implement certain features. It’s unrealistic for many add-on developers! And even if I would: Wo could guarantee that the API for my super-specific use case will get implemented? But aren’t those super-specific use cases what makes add-ons really interesting?)

        I hope this made it a bit clearer why I’m so angry and I certainly hope that Firefox will continue to be a great browser but as I said so many times before: What advantages does Firefox have compared to e.g. Chrome if you take away add-ons and complete customizability? On the technical side you can never dream of beating Google’s developers, so all you have is your community! Don’t throw that away…

        Reply

  4. Travis wrote on :

    You’re shooting yourselves in the foot by doing this.

    Reply

  5. Fredrik wrote on :

    I for one am quite excited about all this! Will be looking to write some WebExtensions to help fill AMO and because the barrier to entry for me as a web developer is now lower.

    Reply

  6. Amartel wrote on :

    I’m confused. Is there anybody, who thinks that killing Xul is a good idea?

    Reply

  7. Celtic_superhero wrote on :

    Soon starts the time where many before loyal users will make the switch to different products.

    Congrats Mozilla that you alienate users of accessibility and customisation featured – that way you loose even more soon.

    No one loves a rebuilt Firefox which is influenced by Chrome for Chrome users in mind.

    If you would be honest you would rename the browser – this is neither Firefox and you are no longer Mozilla. Mozilla was all about features and choice – you are no longer.

    Luckily Otter-Browser, Qupzilla, Brave, Vivaldi and others are carrying on old Mozilla’s legacy.

    Good riddance!

    Reply

  8. kjemmo wrote on :

    I am the developer of a complex overlay add-on. For the past month or two I have been researching my options to port my add-on to a WebExtension.

    There are several APIs that are not yet ready, that I need before I can port my legacy extension.

    With just nine months to the release of Firefox version 57 I’m seriously starting to get concerned if I will be able to port my extension in time.

    The main problem is, that it is a date in time that dictates when WebExtensions will be the only supported add-on type.

    There are no list of minimum requirements or a list of essential WebExtensions APIs that must be available to developers before legacy add-ons are made absolete.

    That means that we as developers have no clue if or when the APIs that we need will be available.

    I have asked about this on the developer mailing list and here:
    https://discourse.mozilla-community.org/t/is-there-some-deadline-for-webextensions-api-availability/13358/3

    And so far the answer is that no one really knows. There is no list of minimum requirements no one knows which APIs will be available and when.

    The strange logic is that a date will dictate when WebExtensions becomes the only add-on type and not a minimum set of features.

    You are just out of luck if an API that you need does not make it before the deadline.

    > 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.

    I would love to focus on migrating my add-on to a WebExtension, but I can’t with the limited list of APIs currently available and It seems that no one can tell me if or when I will be able to do so…

    > 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.

    The truth is that we have no idea what to expect as there is no minimum requirements to WebExtensions.

    What I would like to see and what could give me peace of mind is the following:

    * A clear list of minimum requirements and APIs that will be available when WebExtensions are enforced.
    * A generous transition time of at least six months where all the minimum requirements above is available to developers.

    Without this we need to rely on hope and luck in order to port our legacy extensions.

    Reply

    1. Jorge Villalobos wrote on :

      Can you please post this in dev-addons AT mozilla DOT org? I know that Andy McKay (who leads the WebExtensions API) is finguring out how to make that plan more visible, since now it’s mostly handled on Bugzilla.

      Now, the reason the deadline is a date is because there are many big changes coming to Firefox that will make legacy add-on compatibility pretty much impossible going forward. So, it’s not an arbitrary date we chose.

      Reply

      1. kjemmo wrote on :

        I already did post this at the mailing list and Andy has replied.

        I suggested a list with planned APIs that are still in development in addition to the already available APIs. Here is my reply to Andy (have not heard anything back yet):

        “I suggest that a list of planned APIs is listed somewhere where it’s easy to find for WebExtension developers. It could easily be at the main WebExtension page:
        https://developer.mozilla.org/en-US/Add-ons/WebExtensions

        In addition to the already available APIs a list could be added with the ones that are in development and planned. Please see the screen shot for placement.

        http://i.imgur.com/c6CBC8B.png

        Information such as expected availability (Firefox version) and a brief description of what it does would be great.

        With a list like this assumptions, hoping and guessing would not be needed and it would make it possible for developers to plan when and if to port their existing legacy add-ons to WebExtensions.

        Can anyone support this idea?”

        Reply

      2. Kees wrote on :

        “There are several APIs that are not yet ready, that I need before I can port my legacy extension. With just nine months to the release of Firefox version 57 I’m seriously starting to get concerned if I will be able to port my extension in time. The main problem is, that it is a date in time that dictates when WebExtensions will be the only supported add-on type. ”

        I just responded to the reply Jorge Villalobos to my earlier comment. Above comment by kjemmo is a very good indicator (at least to me) what the current status of WebExtensions is: Still heavily in development and Mozilla requires from add-on developers to ensure that their add-on (most likely created in spare time) is working with Firefox 57 which will be prime-time 28th of November but for a significant number of heavy users (i.e. Aurora/Beta users) even earlier.

        To me the path taken looks like throwing away old shoes before the new ones are completely manufactured. The timing of the change should be longer (it will not help to alleviate the aggravation/anger of the developers who have invested in getting XPCOM based e10s add-ons compatible, but at least the ones who will go to the WebExtensions have sufficient time to make the transition).

        Reply

      3. Kees wrote on :

        > Now, the reason the deadline is a date is because there are many big changes coming to Firefox that will make legacy add-on compatibility pretty much impossible going forward. So, it’s not an arbitrary date we chose.

        When the WebExtensions are not powerful enough then this deadline can become a dead for lots and lots of add-ons which may be the reason that people use Firefox. So instead of making internal changes which result in the removal of classic add-ons the real focous should be on getting the WebExtensions feature complete (i.e. in a state where a large number of features used by add-ons are available in WebExtensions).

        At the moment the checklist is not adding up:
        1. Feature is disabled just after an ESR release – nope it a couple of versions before. Should be a no-go.
        2. WebExtensions are already feature complete and tested. About 50% of the most used addons (say the top 25) are a WebExtension – I cannot answer this one, but to be honest my gut feeling says that this criterion is also not met.
        3. There is at least 2 years* between the first announcement that the classic add-ons will no longer work and the actual removal – doesn’t seem the case to me.

        *: I would like to have this longer, Mozilla would like to have this shorter so about 1.5-2 years would be somewhere in the middle….

        Reply

  9. Rob Crowther wrote on :

    “Firefox 57, November 28th release”

    The sad day when, after 15 years, I will stop using Firefox as my primary browser.

    I’ve been able to work around all the previous dumb stuff only because of XUL-based extensions.

    Reply

  10. DMcCunney wrote on :

    I’ve been using Mozilla code since it was still the code name of an internal Netscape project to replace Netscape Communicator with a next generation Browser suite, and I’ve followed along through Netscape 6 (unusable), Netscape 7, the Mozilla Suite, and Firefox and Thunderbird.

    I liked Mozilla products because of their extensibility. Having the UI implemented in XUL, CSS and widget sets meant I could dramatically change what the products *looked* like via themes, and change and extend them via extensions. I used Firefox because it was the most *powerful* browser.

    That has been steadily reduced. Themes now are at best title bar decorations of a basic UI that can’t be significantly modified. XUL is now deprecated in extensions, with pure JavaScript as the path going forward.

    Now we see Web Extensions as the anointed path for future development.

    I get the impression that the Mozilla devs live in an echo chamber, and only talk to each other. What *users* might need or want doesn’t seem to be a consideration. An example is the Australis redesign for Firefox. I didn’t mind it that much, and had already implemented a lot of what it did through extensions, but I saw a lot of “If I wanted the browser to *look* like Chrome, I’d *run* Chrome!” comments, and the complainers had a point. If Mozilla ever solicited comments from *users* about what *they* thought before imposing this, *I* never saw it.

    The changes outlined on the road map are steadily reducing the reasons I run Mozilla code in the first place. The use of Web Extensions going forward will likely *break* about half of what I have installed, because what they do simply can’t be *done* in Web Extensions unless that API is dramatically extended. (I’ve already gotten a notice from one developer of extensions that I use that development has ceased because he doesn’t see a way to do what his extensions do in Web Extensions, and they’ll simply stop working whan the switch is thrown.)

    Firefox appears to be doing its best to look and act like Chrome. Tell me, Mozilla devs – why should I bother to continue to use Firefox? Why shouldn’t I just give up and switch to Chrome, since it runs under both Windows and Linux and I dual boot? I’m aware of the architectural differences under the hood, but they largely don’t affect what I see and how I use the products.

    And I see the steady erosion in Firefox market share in favor of Chrome, so *large* numbers of users have already made that decision.

    Mozilla is funded by cooperative agreements with Yahoo, Baidu, and Yandex, so the money in Mozilla developer’s paychecks doesn’t come from actual product sales. But those agreements are predicated on Firefox driving traffic to those partners, and as Firefox usage declines, so does the benefit the partners derive from funding Mozilla. (And Yahoo has been acquired by Verizon and is being re-branded. Will Verizon see fit to continue the agreement? I’ll be rather surprised if they do. Then what does Mozilla do for funding? How many developers insulated from what the market wants will get layoff notices as funding goes away?)

    Mozilla seems to be totally out of touch with its user base, and declining steadily as a result. It doesn’t matter what your business model is – if you don’t *have* users, you cease to exist. That’s pretty much what I see happening to Firefox, and by extension, to Mozilla.

    Mozilla looks like it’s in the process of committing suicide, and is bringing it upon itself through utter failure to communicate with its user base and pay attention to what they want and need. It will likely be the source of some classic B-school studies on how *not* to run a project like that.

    I’m profoundly sorry about that, and I’ll continue to run Firefox as long as I can, but there will be a time when I can’t because it can no longer do what I want, and that time looks like it will be sooner rather than later.

    Reply

    1. Mike Miller wrote on :

      I will stop using Firefox after version 57 is released as it just won’t do enough of what I need after that time. The extensions being exterminated are exactly why most people continue to use the browser.

      This is a terrible move by those who have lost touch with the main users of their product.

      Reply

    2. Kees wrote on :

      > (I’ve already gotten a notice from one developer of extensions that I use that development has ceased because he doesn’t see a way to do what his extensions do in Web Extensions, and they’ll simply stop working whan the switch is thrown.)

      This could (and still can) be prevented by ensuring that WebExtensions match the feature set used by classic add-ons before the become the only option for add-ons.

      Just thinking out loud: Having compatiblity shims in classic add-ons would help with the transition so that you can have a classic add-on and use more and more WebExtensions when they become more and more feature complete. Of course the transition timeframe should be longer than 6 monts, it should be about 2 years or so…

      Reply

  11. Simon wrote on :

    Mozilla needs a shakeup in management – the decisions made are baffling. You are removing the only things that make your browser different. Why would anyone bother to download and install your product at that point when Chrome or whatever else that is bundled in is more or less the same. You cannot afford to marginalize your remaining base of users. WAKE UP!

    Reply

  12. CuriousGeorge wrote on :

    I like this idea a lot. I find it frustrating when I develop a website for Chrome and it doesn’t work properly for the <10% of people who still use Firefox. Luckily, killing XUL will be the nail in Firefox's coffin, thereby fixing the problem.

    Thanks again to Firefox devs for their great help in moving everyone over to Chrome.

    Reply

  13. tim wrote on :

    What about the Seamonkey-Version of the XUL extensions? Because that’s the browser to go, when firefox stops using XUL (as i guess they won’t migrate soon to another UI).

    Reply

    1. Jorge Villalobos wrote on :

      As far as we know, SeaMonkey will continue supporting legacy add-ons for the time being. That might become harder in the future since SeaMonkey code is largely based on Firefox code.

      Reply

  14. Neil Hunnernan wrote on :

    The only addon I truly care about is Firegestures. It is a XUL addon and there’s no indication it will be ported to Webextensions.

    EVERY mouse gesture addon in Google Chrome sucks. Most are literal malware, and the few that aren’t work frustratingly inconsistently. They simply don’t perform acceptably.

    I have seen no indication that mouse gestures will work well once Firefox murders its legacy addon system. When that happens I’ll either switch to the inevitable Firefox fork or Vivaldi. I’ve been using Firefox as my primary browser since it was called _Phoenix_, and you’re pushing me away.

    The vast majority of your community hates that you’re doing this, Mozilla. Response has been overwhelmingly negative since day 1. Most of us simply don’t understand why it’s necessary. Can you explain that?

    Reply

    1. Jorge Villalobos wrote on :

      You can find an explanation in this blog post.

      Reply

  15. Danny April wrote on :

    Jorge why removing customisation?

    It started already with Australis – the reason you removed that was not bc security – you can’t expect us to believe that it was for Sec reasons!

    Changing the UI is not compromising anyone at all. You did that bc you want to broaden your user base beyond power users. And bc users like Chrome or IE users don’t use a “bloated” prod – our pet features had to go.

    Oldskool Mozilla saw it as their obligation not to cater only noobs interests.

    What you are doing now is boing down to the lowest common denominator, supporting only amateurs interest. Opera did the same.

    It’s a shame you adopted a money oriented mentality which is a shame for an open source company. You are not better than Google or Microsoft – you are abandoning us for influence money and market share – and in 2 out of 3 points you are still failing.

    An open source project without user loyalty is not better than a close source one.

    Where is good old Mozilla and why it was replaced with that anti loyal and money and influence hunting imitation of a once proud and loyal organisation???

    Reply

    1. Jorge Villalobos wrote on :

      There are some UI elements that are security sensitive, like the identity box, but that’s not the main reason that UI customization is being significantly restricted. The main reason is that add-ons that do this are very dependent on the UI begin a certain way, and breaking easily when it doesn’t. This means making big UI changes in Firefox (like Australis) lead to lots of anger from users and add-on developers, and add-ons end up being inevitably abandoned every time. Restricting APIs in a way that make them more future-proof largely avoids these problems. It’s a trade-off, of course, and some great add-ons can’t be implemented in the same way, or at all, but we believe it’s a net positive.

      Reply

      1. Danny April wrote on :

        It is no one’s benefit you could have chosen to introduce UI customisation in bundled component or hard coded form. This is not about breakage – You do not want to support features like that any longer.

        Not going to use your browser any longer. Again we do not want a browser which looks like Chrome and works like Chrome. Hope you find enough replacement users BC one is for sure – without us vocal supporters you will have a hard time.

        Reply

        1. Danny April wrote on :

          Here are some nice replacements for all who are fed up with Mozilla’s fascination with Chrome:

          Otter browser
          Qupzilla
          Brave
          Vivaldi
          Qutebrowser

          Jorge, how Google handles their UI is not at all desirable. Too bad you can’t understand that.

          Have fun in Chrome imitation land!

          Reply

  16. Adam wrote on :

    For years now I have written extensive comments on this blog in response to Mozilla’s foolish decisions, especially regarding addons. They were in vain, however, since Mozilla is intent on transforming FIrefox into Chrome and thereby destroying itself.

    I’ve used Firefox since it was Phoenix. Firefox 56 will be the last version of Firefox I use. May the Phoenix rise again.

    Reply

  17. Danny April wrote on :

    Bye Jorge I hope you and me or I and another Mozilla guy will never meet each other – because I feel VERY motivated to belt you one right in the face!

    You guys are spineless betrayers and Google fanboys.

    Reply

  18. John Nagle wrote on :

    So Mozilla is killing Jetpack, the Add-On SDK, too. After pounding add-on developers into using it.

    The question now is, does Mozilla still have enough market share to justify conversion. My add-on usage has dropped 50% in the last year, in lockstep with Mozilla’s declining market share (6.58% in January 2017.) Should we bother?

    Reply

  19. anon wrote on :

    Contrasting many it seems, I’ve just switched to firefox for privacy. Removing the old addon system was justified by mozilla as necessary to implement better browser security. With the use cases browsers handle, sandboxing and guarding against RCE takes priority over convenience of some addon users.

    I, for one, fully support mozilla’s decision to kill off the old addon system if it’s holding the browser back.

    Also, attacking people for doing something they are within their rights to do is down right pathetic.

    Reply

  20. Joe wrote on :

    To me WebExtension is the way to go, but when it is reacher than Chrome’s one. Not when it is a lot less powerful. Firefox needs to have something that attracts people to it. If the idea is to follow Google, then why not using its browser as well? Why anybody should be interested in Firefox?

    I know you guys want to extend WebExtension, but at least until FF 57 is released, there is no way for WebExtension to be more powerful that what Chrome already has. This means users are get better support if they dump FireFox and switch to Chrome, right? Normal users wouldn’t return back to Firefox if they can get what they want in Chrome.

    This timeline you propose will definitely affect Firefox. I do understand the need to move to WebExtension, but it is clear at this stage WebExtension is not yet powerful enough for most of developers and hence they will give up supporting Firefox. For instance WebExtension has no plan for supporting access to password manager, does this really mean all password related extensions are going to die?

    Reply

Post Your Comment