Mozilla Add-ons Community Blog
Firefox logo
Categories: compatibility developers releases

Timeline for disabling legacy add-ons on addons.mozilla.org

82 responses

Mozilla will stop supporting Firefox Extended Support Release (ESR) 52, the final release that is compatible with legacy add-ons, on September 5, 2018.

As no supported versions of Firefox will be compatible with legacy add-ons after this date, we will start the process of disabling legacy add-on versions on addons.mozilla.org (AMO) in September. On September 6, 2018, submissions for new legacy add-on versions will be disabled.  All legacy add-on versions will be disabled in early October, 2018. Once this happens, users will no longer be able to find your extension on AMO.

After legacy add-ons are disabled, developers will still be able to port their extensions to the WebExtensions APIs. Once a new version is submitted to AMO, users who have installed the legacy version will automatically receive the update and the add-on’s listing will appear in the gallery.

For more information about porting legacy extensions to the WebExtensions API is available on MDN.  We encourage legacy add-on developers to visit our wiki for more information about upcoming development work and ways to get in touch with our team for help.

82 comments on “Timeline for disabling legacy add-ons on addons.mozilla.org”

  1. zakius wrote on

    “For more information about porting legacy extensions to the WebExtensions API is available on MDN. We encourage legacy add-on developers to visit our wiki for more information about upcoming development work and ways to get in touch with our team for help”
    sure, where exactly can I find information how to properly implement mouse gestures and keyboard hotkeys? working on each and every possible page, working on userchrome, aware of context (executing different action if performed over website area, different over sidebar, different over tab bar etc.)?
    and while we are at it: when can I find help in providing native user interface, using the same colors and shapes users know and feel confident with for interface elements?

    1. jase wrote on

      I couldn’t answer your first question, but as for the second one, following the Photon design guidelines (https://design.firefox.com/photon/welcome.html) should be sufficient to making your extension blend in nicely with the Firefox UI. The site also provides a wealth of Photon-style SVG icons you can use, as well as instructions for making your own. Examples using the context-fill and context-fill-opacity properties should be available, too.

      1. zakius wrote on

        The thing is
        1. Photon is terrible in terms of both usability and looks
        2. I meant systemwide consistency across all browsers (since WE is pretty much Chromium Extensions API and there is polyfill allowing WE to run in Chromium)

        and to be honest: I was being salty as both things are impossible in WE

        additionally XUL exposed many nice interface components that are not available currently (maybe web components will change this some day…)

  2. Peter Bhat Harkins wrote on

    I got an email saying I had an account and active add-on. It’s possible, but I don’t remember it. I tried to reset a password on my account and was told I don’t have one. What gives?

    Sorry to use your blog for a support request, but when I responded to an email it linked to https://wiki.mozilla.org/Add-ons#Getting_in_touch. Nothing here talks about account/developer support and this doesn’t mean signing up for yet another user account. Thanks for any help.

    1. Caitlin Neiman wrote on

      Hi Peter, thanks for reaching out! Can you check to see if you received a reply to your email yesterday?

  3. kwerboom wrote on

    Could you at least archive the last version of legacy add-ons the way you archive older versions of Firefox so that people have a safe, official repository for these add-ons should we need them for an older machine we are trying to get running on a network? You do realize Firefox is the last and most recent web browser to support both Windows XP and Vista.

    1. Caitlin Neiman wrote on

      Unfortunately, we don’t have the capacity to create and maintain an official repository. From other comments, it does sound like other groups are backing up legacy extensions; these groups might also be open to making them available as an archive. But, to be clear, there will be no supported builds that are compatible with legacy extensions after support ends for ESR 52 on September 5.

      1. Robert Ab wrote on

        Caitlin:

        Can you at least delay disabling legacy addons?
        => Session Management API was planned to ready in Q3 2018, now this date is moved to 2019; they are few other important APIs like Toolbar API. Can you wait with old addon disabling at least until these addons will be ready (plus time needed to correct errors/bugs in new API + few months for webextension developers to introduce new API to their WEs),
        => Windows XP machines will be not forever. Few additional years will be more than enough for most users.

        I understand that the cost of legacy addon repository is an important factor. But maybe lower a cost by converting it into a static/frozen database of these addons and just disable submissions of new addons, and any other changes. Or convert legacy addon repository into ftp database. Possibilities are endless here.

      2. Graham Perrin wrote on

        In IRC I was advised that the .xpi files will remain available.

        1. Jorge Villalobos wrote on

          That’s not correct. Once the files are disabled, they will not be available.

          1. Robert Ab wrote on

            These .xpi files will take approx. 100 GB. It is not that much. Why they cannot be available for example on ftp server? You could also make this database read only, without new submissions, and without anybody from Mozilla needed to do anything with that other than keeping backup copies.

            So it is really to keep only 100 GB on the server.

          2. Robert Ab wrote on

            These .xpi files will take approx. 100 GB. It is not that much. Why they cannot be available for example on ftp server? You could also make this database read only, without new submissions, and without anybody from Mozilla needed to do anything with that other than keeping backup copies.

            So it is really to keep only 100 GB on the server.

            Otherwise, my understanding would be that removal of XUL addons is done by purpose other than need for database maintenance. The real purpose would be to stop people from using FF52 ESR and FF56.

      3. Chuck Baker wrote on

        “Unfortunately, we don’t have the capacity to create and maintain an official repository.”

        Really? On Amazon I can get a 2TB hard drive for less than $60. That’s probably 10 to 20 times more storage than would be required. If Mozilla can’t afford it, I’ll gladly buy one and donate it.

        1. Jorge Villalobos wrote on

          Storage isn’t a concern. Standing up the repository and keeping it running has both human and monetary costs. Anyone is free to do the work, and some people are doing exactly that.

  4. glandium wrote on

    What about Thunderbird and Seamonkey? When is their last release with support for legacy addons, and does that match your timeline?

    1. Jorge Villalobos wrote on

      They have their own add-ons website now: https://blog.mozilla.org/addons/2018/07/17/the-new-thunderbird-add-ons-site-is-now-live/

      There are some preliminary plans to implement something like WebExtensions for Thunderbird, but I don’t think there’s a timeline for it.

  5. sjjdkwoa0xoem wrote on

    It’s just throwing the labour of people into junk.

    When companies collect, stockpile and store indefinitely personal data of people, they don’t cry “we have too little disk space”. But when companies can delete something they don’t need, like legacy ff addons, or coursera videos, they just do it, and they don’t care that it is cheap not to delete this data.

    Mozilla, I insist that you should keep all the source code of all the old addons available. It doesn’t matter that they cannot be run on current firefox. It is large amount of code people have spent their holydays creating. It is still valuable, it still can be used for education purposes. If you claim that you don’t have space to store them, you can create a new org on GitHub, convert each old addon release history into a git repo and put there, so GH would store them, not you. This legacy mustn’t disappear.

    1. Ulf3000 wrote on

      waterfox community already backed up the legagcy extensions .. but since many of them are so worthless , itll take some time to sort out the good from the bad stuff

    2. Robert Ab wrote on

      I agree 100%.
      Or create ftp database, in similar way like all firefox versions are available now.
      This database does not to be updated, it can be static/frozen. New legacy addon versions can be stopped.

  6. Bernadette B wrote on

    How about fixing Bug #1291841 before disabling access to the only cookie-management add-ons that work?

    My upgrades to Firefox 57+ are blocked until CookieShield, Cookie Block, and Cookies Manager+, or their functional equivalents, exist.

    This is not the add-on developers’ fault; they have been blocked on this missing feature for more than two years now.

    The correct order of operations is to add the necessary APIs, then give the add-on developers a few months to port to them and then start talking about hard-disabling non-upgraded add-ons.

    1. zakius wrote on

      this person knows how to do stuff, and I believe many other people told you to do it this way, but you still decided to break everything

    2. Caitlin Neiman wrote on

      Hi Bernadette, thanks for your comment. We are aware that a small group of legacy developers are unable to port because they are still waiting on APIs to land. Bug #1291841 is still on our roadmap and we’d like to implement it, but our engineering resources are limited and are currently focused on other priorities. At this time, I would recommend that affected developers continue watching this space for updates about API development or subscribe to individual bugs to track progress for particular features.

      1. Robert Ab wrote on

        Caitlin:

        Can you at least delay disabling legacy addons?
        => Session Management API was planned to ready in Q3 2018, now this date is moved to 2019; they are few other important APIs like Toolbar API. Can you wait with old addon disabling at least until these addons will be ready (plus time needed to correct errors/bugs in new API + few months for webextension developers to introduce new API to their WEs),
        => Windows XP machines will be not forever. Few additional years will be more than enough for most users.

        I understand that the cost of legacy addon repository is an important factor. But maybe lower a cost by converting it into a static/frozen database of these addons and just disable submissions of new addons, and any other changes. Or convert legacy addon repository into ftp database. This can be really simple archive – we do not need reviews or other not important stuff, just all addons, plus description containing general information about addon and information about different versions in text/html file. Possibilities are endless here.

        Also I read that Mozilla addon team was made smaller. In fact, should be bigger, until all important APIs are ready.

      2. kjemmo wrote on

        A small group?

        UI options for webextensions are still very limited. There is still no toolbar API and there are many hundreds toolbar based add-ons…

        That is just one example.

        Create an archive, so all this work is not lost. At least till you can offer a real alternative.

      3. Andrés wrote on

        What about pausing this deprecating process until it can safely be performed? If you don’t have resources to fix all the bugs before the time limit, then set the time limit further in time, or just don’t set a time limit for now.

        The time limit is set by you, not by an external entity, so if WebExtensions is still not ready (it is not, lots of blocking bug remain) you can’t deprecate XUL addons and set a time limit that will shoot you in the foot (and you are confirming that you will shoot yourself in the foot by saying that there are not enough engineering resources to fix the bugs before the deprecation).

        “I want to make a new car, I will start using it when I have built it and later I will scrap the old one I have. The new car still lacks seatbelts and windshields, but everything else works and it can ride the highway, so it is time to start using it and scrap the old car!”

        1. zakius wrote on

          it’s way too late for that unfortunately, they flipped the kill switch a year ago and despite seeing all the problems refuses to make things easy for both users and develoeprs

          and currently the new car misses not only windshields and seatbelts but also steering wheel and fuel is leaking in some places, but don’t worry!@ it drives faster due to removed rear seats (it’s lightweight now!)

      4. zakius wrote on

        it’s been a year and still some core features are unavailable, do you really believe that these developers will just sit waiting for you while they are barraged by users’ complains, in many cases harassing THEM for your incompetence?

        flipping the kill switch early was the worst thing you could do
        for users
        for the web
        and for your own product

        and to make it even worse you openly refuse to provide proper support for some features like mouse gestures and keyboard shortcuts (including overriding and disabling default ones)

        yes, I am mad
        maybe I’d be less mad if you clearly admitted you messed up, maybe if you did some damage control (for example making exceptional 56LTS supported till all expected APIs hit or at least supporting 52 till then) but instead you target your limited resources at PR stunts, promising you’ll help finding replacements for our extensions… but when we actually tell what we need there is no reply AT ALL, since you don’t want to admit that not only replacements don’t exist but also are impossible to implement with the current (and foreseeable) state of WE

      5. Kees wrote on

        “We are aware that a small group of legacy developers are unable to port because they are still waiting on APIs to land. ”

        Can you (or anybody else add Mozilla) provide an answer why there wasn’t done a proper investigation of the top 25, top 50, top 100 add-ons which were still more or less actively developed *classic* (XUL/XPCOM) based add-ons and a list of features Required(!) for WebExtension API’s to ensure that at least the possibility exists of porting the classic add-ons?

        I do totally understand the need to be on feature parity with Chrome’s API as you based WebExtensions on its API, however BEFORE removing the possibility to run the classic XUL/XPCOM based add-ons there should have been a project to ensure that the top 50 add-ons (add you may have excluded add-ons like Firebug which is replicated in the developer tools now) could run without problems and then about 1 year later the featureset of the top 100 add-ons could be added.

        WHY wasn’t this done, and what will be the plans for the near future To Ensure that this gap is bridged???

        (From a users point of view I’m much more interested in a TileTabs WE add-on which behaves like the Classic XUL/XPCOM based one than in some theming related API – As that is something I have given up already [extensive theming as we have in the days of Firefox 1.0-4.0).

        Except for Bugzilla, where is there a list of classic XPCOM API’s which are going to be available in the coming 6 months and where is there a list of XPCOM API’s with there (to be) WE counterparts?

  7. Artem S. Tashkinov wrote on

    Most XUL add-ons are still _miles_ better than your WebExtensions faeces and offer the features which are not and will never be available. Literally thousands of XUL addons have no WebExtensions alternatives and now you’re saying you’re just going to erase them without a trace? What the hell? There are alternative web browsers based on the old Firefox/Gecko code which can perfectly run your old add-ons. Don’t kill something which doesn’t really need any maintenance.

    How much does it cost you to create https://archive.addons.mozilla.org and leave old add-ons be? You can disable uploading of the old add-ons and don’t let people comment on them. That would be enough!

    Do you even begin to realize how many users you’ve lost to your overzealous desire to modernize your web-browser?

    Don’t even get me started on how horrible your modern AMO website looks. The old webdesign was a thousand times better: more information on the screen, easier to use, easier to navigate. I hope Firefox will lose so much of its market share that you finally replace the people who are responsible for the development.

    Firefox used to have its soul, its unique appearance, its unique features. Now it’s FireChrome.

    1. Caitlin Neiman wrote on

      Hi Artem, thanks for your comment. From a previous comment, it sounds like some groups have backed up legacy extensions. Unfortunately, we have limited resources and do not have the capacity to create and maintain an archive.

      1. Alex G wrote on

        Hi Caitlin,

        I’m developer and manager in software development company and clearly understand that resources are ALWAYS limited. It’s question of priorities. In your case top priority is given to marketing and losing your power users, please think about this.

        1. zakius wrote on

          I can sign this in blood in needed

      2. DasKleineTeilchen wrote on

        “Unfortunately, we have limited resources and do not have the capacity to create and maintain an archive.”

        ??????????

        sorry, what?!? the mozilla-foundation has not the capacity to maintan an archive of something like ~100GB?!? thats like 3 USB-sticks for 15$ each.

        this is bullshitting on so many levels and you know that, right? why are you giving people such nonsense as justification for a VERY bad decision on your side?!?

  8. jore wrote on

    Fully agree with the very correct views and opinions upstairs.

  9. Duane B wrote on

    How about fixing the addon-blocking bugs first?

    Lots of people have been holding at 52.x or 56.x until important addons have been upgraded. The addon authors have been waiting until BLOCKING BUGS IN FIREFOX like Bug#1291841 (APIs required to implement cookie-management addons are not implemented) are fixed.

    Since you’re “Add-ons Community Manager”, it’s YOUR JOB to know which add-ons are popular and not yet updated. And then to SEEK OUT the authors and resolve the issues that are blocking them.

    While the add-on authors have been waiting fairly patiently, it seems that Firefox devs enjoy playing a cruel game: the ball’s in our court, we’re not giving it back, but YOUR clock is ticking!

    1. Caitlin Neiman wrote on

      Hi Duane, thanks for your comment. I can certainly appreciate your feelings.

      We are aware that a small group of legacy developers are unable to port because they are still waiting on APIs to land. Bug #1291841 is still on our roadmap and we’d like to implement it, but our engineering resources are limited and are currently focused on other priorities. At this time, I would recommend that affected developers continue watching this space for updates about API development or subscribe to individual bugs to track progress for particular features.

      If any community members are interested in submitting a patch for bug #1291841, I’d be happy to help get them started.

      1. Christian wrote on

        Right. But what about the many thousands of loyal Firefox users who are desperately waiting for those “small group” of add-ons to be ported because they depend on them? I am one of them and we are holding on to those old versions because the newer ones are broken for us.

  10. Unexpected Bill wrote on

    I’m exceedingly disappointed to hear that the “classic” browser extensions library will be disappearing. This is an enormous disservice to anyone who is running an old browser for whatever reason — and sometimes there *are* valid reasons and use cases. There’s also the matter of nominally compatible offshoots of the Firefox browser that would still utilize the older extensions.

    I’m personally holding on to Firefox 52 ESR for a while yet, as the later versions can’t be customized in some ways I find essential. For now I suppose the solution is to archive the last versions of any extensions I need or want.

    At the very least, I hope you might leave the last versions of old extensions in some kind of repository, or download location.

  11. Alex G wrote on

    Caitlin,

    It seems that Firefox team decided to completely discard their power users who like incredible Tab Mix Plus features. My only concern is your management lie: first you announced XUL addons deprecation and provided one year for developers to adopt their addons. TMP was extremely popular, but no API work for it was done. Then your team finally made APIs list required for this addon to function and said that resources are limited, that is not our priority etc. There is a problem with management: no planning, thinking about your users. You started break thing much more faster than before. And you are losing your most loyal users and developers. Sad.

    RIP, Firefox.

  12. Richard Paul wrote on

    I’ve long since moved over to Basilisk browser because session management, cookie management and tab grouping has been broken and unimplementable since FF57+.

    It doesn’t help that a lot of this work has since also been punted into the (2019+) long grass. Firefox doesn’t actually have me as a user any more (nice work there what are you going to do next to me? Break sync support I guess to really screw us over) and won’t get me back to what looks like well into the 2020s, if it even exists still.

    Well done by the way, you have managed to shrink your own global market share by over 20% (3% of the market) in the last year :slow clap:

    1. Mario wrote on

      >Well done by the way, you have managed to shrink your own global market share by over 20% (3% of the market) in the last year :slow clap:

      And that was when people still had the option to use a pre Quantum ESR. All of those just got kicked out yesterday

  13. J Little wrote on

    Caitlin, I know your “engineering resources are limited”; that’s why I’ve been quietly waiting without too much fuss for the APIs to land.

    If mozilla.org would show the same sort of patience and wait for Quantum to reach feature parity before aggressively “encouraging” (in ways reminiscent of “Upgrade to Windows 10!”) people to migrate to WebExtensions-only, I wouldn’t be complaining.

    What I frankly EXPECTED to happen when the WebExtensions switch was announced was that both interfaces would be supported while the little “legacy” warning boxes on about:addons gradually disappeared as the extensions auto-upgraded, and everything would be transparent.

    Maybe I’d have to find equivalents to one or two of my extensions. That’s the way breaking API changes are normally managed.

    But Firefox development was more impatient and urgently wanted to decommission the old code, so dropped the old APIs around 57/58, long before the WebExtensions API was feature-equivalent.

    The big PITA for me is that now it’s a flag day upgrade. There is no FF version that supports my XUL addons *and* the WebExtensions equivalents.

    Grumble, I don’t like, but I understand how it shifts the burden from your devs to me and thus frees up more of your engineering resources, so I’m willing to tolerate it. I can either hold at 56 or use ESR.

    I have to manually watch the available extensions and see when I should schedule my flag day.

    What SHOULD have happened at that time was a posting listing the top 50 (or so) legacy add-ons and the reasons they aren’t upgraded. Reasons like:

    * Developer unreachable
    * Developer says not interested in porting (and list alternatives or say “there is none, someone please write one!”)
    * Developer working on it, but experiencing a round tuit shortage; have patience
    * Upgrade blocked on missing FF feature (Bug#xxxx)

    Followed by a serious effort to empty that last category before the end of the ESR period. Keep tracking them and help me schedule that flag day.

    As I said, that’s what SHOULD have happened, but didn’t.

    What we have now is a bigger mess: now you’re breaking the ability of XUL add-on developers to tell me there’s a new version available (by auto-distributing a version with a notification built in).

    “Good, cheap, fast: pick any two.” Resources are limited, so “cheap” is non-negotiable. My complaint is that by insisting on a fixed schedule, you’re choosing “fast” over “good”: waiting to shoot the old horse behind the barn until the new one is ready.

    1. John G wrote on

      There are a lot of salty comments on here, which is no surprise given the reasons that you so clearly articulate here. As a Firefox user since almost launch times, I feel that same rage in my heart, but as a jaded programmer, I can’t even bring myself to rage, only to feel disappointed. I’ve put a few dollars in the donation jar over the years, but not enough to feel like I can impose demands. In the meanwhile, I imagine I’ll wind up migrating to some bespoke browsing solution until it becomes unbearable. No solutions here, but I wanted to say thanks for writing your perspective up — you nailed it and I can only hope someone at Mozilla will hear.

  14. Peter M wrote on

    If users opt not to update to Quantum, will they still be able to use previously downloaded legacy add-ons with a previously downloaded version of ESR 52 or will everything just stop working at some point?

    1. Caitlin Neiman wrote on

      Yes, users who remain on ESR 52 will continue to be able to use previously downloaded legacy add-ons. The caveat is that running an unsupported browser leaves users open to security vulnerabilities, so we don’t recommend taking this route.

      1. Robert Ab wrote on

        Just a rhetoric question: And whose fault is that? That users will be running unsupported browsers open to security vulnerabilities. First Mozilla introduced HUGE REGRESSIONS in FF57, and then has been doing too little to provide APIs for webextensions in timely manner. You should provide sufficient APIs for 50 the most popular addons BEFORE removing support for XUL addons.

        And now it is really easy for you to blame users that they do not want to use still faulty Firefox Quantum. Firefox 56 was the best Mozilla browser. It was much faster then previous versions, and yet it supported XUL addons. Why you did not create FF56 ESR, I do not know.

        Move enough engineering resources to addons team, so you will be able to complete all missing API in the next 6-12 months and then you can continue Quantum revolution.

        1. Juraj M wrote on

          It’s time to move on. For developers it’s very hard and time consuming to keep old add-ons running. The architecture was wrong from the beginning and this decision was inevitable.

          Even when it seems wrong and painful, this will allow faster growth with more and better features in Firefox.

      2. Peter M wrote on

        Thanks for the info. I use the latest Firefox Quantum at home, but at work our IT department has opted for ESR 52 for now. I guess it works better with some of our in-house apps and some folks are also attached to some of the legacy extensions, so we don’t tend to update so quickly.

  15. Tim McCormack wrote on

    Until Firefox Quantum supports session management, I fear I’ll have to stay on ESR 52. I was expecting to be able to make the switch to Quantum as soon as the session management WebExtensions APIs landed, but those have been pushed off.

    Unlike many other ESR users, I don’t trust Firefox clones, so I plan on sticking with ESR until the next big security vulnerability hits; then, I’ll have to make some tough decisions.

    Firefox ESR has been wonderful, and I applaud Mozilla for maintaining a “stable” release line. Please commit to following the spirit of that stability by supporting security fixes in pre-Quantum ESR for an additional year, since the price of the breaking changes in Quantum are so great.

    1. Robert Ab wrote on

      I would recommend Waterfox 56.2.2 + Session Manager
      https://blog.waterfoxproject.org/

      But if you do not trust Firefox clones, then maybe try Firefox 56 + Session Manager.
      FF56 is definitely faster then FF52 ESR.
      Speed: FF56>FF55>>FF54=FF53>>>FF52

      1. Peter M wrote on

        Thanks for the tip. I just started using it a couple of days ago, and so far it works well. I’ve discovered some nice extensions that work in Quantum but not ESR 52, but there are also several legacy extensions from ESR 52 that I’ll miss and can’t find a good replacement for. This great browser lets me run both old and new and seems pretty fast as well! I’m surprised that the corresponding version of Firefox wasn’t offered in the ESR group at some point.

        1. Chog Electrogasm wrote on

          Oh, that’s easy! Mozilla would much rather Firefox of any generation not be mentioned along a competitor, even if not doing so might have lost it some fraction of a potential user along the way.

          I mean, take a shot at managing thus: I’ve had absolute hell in core-use legacy extensions (including ones that I have every legal and paid right to use, being attached to purchased applications I own and use regularly) that are greyed out, apparently in permanence, with the bright and cheery ‘Look for alternatives!’ And guess what: there aren’t any. Most of the ones I’ve had go down the chute are either replaceable with buffeted ‘freeware’ with ad crap in the configuration or, worse, in the outputted product the application is meant to provide- and in most cases, there isn’t any real alternative at all, at least not any that does the job I need it to do, and without splashing a ‘look-a-me’ pay blurb on each page of a project.

          I never thought I’d say this, but more often than not I’m using Chrome, of all things, because it’s so far rare that it’s broken or rejected any of the add-ons I need to make use of. Firefox is a great browser, as in looking at webpages… but very slowly, and less slowly as time goes on, that’s all it’s good for as I can use it.

          I’m glad Waterfox and Basilisk were mentioned above (I did know about WF, but I hadn’t looked into it, and Basilisk was a complete unknown until the last 45 minutes or so for me); if one or both can do what Firefox used to, then Firefox and Mozilla can go become a drop in my Mosinee and past tense for me as a user. Thunderbird is already out of Mozilla’s hands, and I’m happy to be a user there for an application both useful and with an owner and updater that gives a shit about it.

          Firefox: may you live in interesting times.

  16. Robert Ab wrote on

    This is the best example of how users are ignored. Mozilla will do everything they want, without taking into account the requests and suggestions from users.

  17. Greg Aouizerate wrote on

    …
    Sad !!
    …

  18. JustOff wrote on

    You say you don’t have 100Gb for the ftp archive? Don’t make me laugh, you just don’t care of the legacy you based on. Shame on you, Mozilla.

    1. Zaba wrote on

      You need bandwidth too. Calm down.

      1. DasKleineTeilchen wrote on

        sorry, bandwith from a 100GB-archive where each .xpi may have something like 1-2 MB file-size?!? that cant be more than a drop, compared to the daily downloads of the browser itself, which has something like 50-100MB each.

  19. Guthrie Bowron wrote on

    It’s all unfortunate, though understandable. Thank you for your work, Caitlin. Energies should be directed to Mozilla as an organisation, not to you in particular; however, you _are_ the nearest (or most accessible, in this case) representative of Mozilla-as-an-organisation at hand.

    The XUL to WebExtension migration process has been punctuated with an unfortunate series of what appears (at least to add-on developers with ‘legacy'[1] add-ons) to be managerial blunders, weak decision-making, leadership with insufficient foresight, and a desire to do *something* (or *anything*) to stop the browser’s increasing slide into irrelevance.

    This has resulted in what looks to be mismanaged priorities. This isn’t to say that Mozilla’s priorities are unimportant, or even necessarily wrong, but that they _look_ to be mismanaged. This mismanagement, which is really shades of ‘sounds good on paper; doesn’t end up working as well’ and ‘good design; poor implementation’, is what has landed us where we all are in the present time: both as users and as developers.

    In other words, what we’re all saying here, as add-on developers and as users, is that Mozilla has left many of us between a rock and a very hard place. There’s no way back, because 52 ESR is effectively deprecated. Similarly, there’s no way forward, since WebExtensions API as it stands now doesn’t cut the mustard, and won’t cut the mustard into the foreseeable future, since admittedly limited resources pushes what were once plausibly concrete timelines into a hazy temporal indefiniteness.

    I direct the following paragraphs to Mozilla, the organisation. It is a plea to action, and to redress.

    Mozilla, what we need is _engagement_. There are multiple stakeholders here, with a variety of interests, needs, and requirements. You need to, as an organisation, take them all into account, moving forward. Since there’s a bit noise-making in these comments from some of these same stakeholders (there are more; these are just the loud ones), _something_ has broken down, somewhere in the _engagement_ process. What shall we do, moving forward?

    Mozilla, where is WebExtensions now, where do you want it to be this time next year, and do you think that you can get it to that level, within that timeline?

    This is imperative, because I know that Mozilla exists partly because Google, likely your largest single financial donor, allows you to. You might be able to afford to bleed functionality, but Firefox is very much like Chrome now. There isn’t much, on the surface, separating them, and much in Chrome’s favour (a larger add-on ecosystem, greater resources, more influence in web standards).

    *Some questions:*

    Open web advocacy aside, why would the average individual choose Firefox over Chrome?

    Do we gain more users by being more similar to the pace-setter, because similarity (homogenisation — some call it ‘standardisation’) is more beneficial than dissimilarity?

    Do we lose more users by being more dissimilar to the pace-setter than not, because dissimilarity is less beneficial than similarity?

    **

    [1] ‘Legacy’ is a loaded adjective, and the kind of word used for software that differs from what replaces it by virtue of it actually working. One may as well replace every instance of ‘legacy’ with ‘outdated’, for Mozilla’s purpose. It has the same meaning, but is more forthright about its intended meaning.

  20. Nodetics wrote on

    People who are upset about losing support for legacy add-ons? What extensions are you still missing specifically?

    1. Peter M wrote on

      I’m not necessarily upset about having to upgrade, but here are some legacy extension that I wish could function in Quantum:

      Add to Search Bar
      https://addons.mozilla.org/en-US/firefox/addon/add-to-search-bar

      Context Search
      https://addons.mozilla.org/en-US/firefox/addon/context-search

      Link Checker
      https://addons.mozilla.org/en-US/firefox/addon/linkchecker

      Pinger
      https://addons.mozilla.org/en-US/firefox/addon/pinger

      It’s All Text
      https://addons.mozilla.org/en-US/firefox/addon/its-all-text

      Save Text to File
      https://addons.mozilla.org/en-US/firefox/addon/save-text-to-file

      Find and Replace for Firefox
      https://addons.mozilla.org/en-US/firefox/addon/find-and-replace-for-firefox

      1. def00111 wrote on

        Simple Context Search
        https://addons.mozilla.org/firefox/addon/simple-context-search/

        Save Text To File already works with Firefox Quantum.

        Find & Replace for Text Editing
        https://addons.mozilla.org/en-US/firefox/addon/find-replace-for-text-editing/

        1. Peter M wrote on

          Thanks for the update on Save Text to File. It downloads but does not seem to work in my version of Quantum (61.0.2)… maybe it’s conflicting with some other extension so I’ll try turning things on and off and then see what happens. The Find and Replace for Text Editing is a great extension and I have used it for a few months, but it flakes out for some reason every now and then on very long textareas. Also, if I accidentally make a replacement I actually didn’t want to make, it doesn’t allow me to hit ctrl-Z to undo the way the other one did. In other ways, though, this new version is a lot better (such as in highlighting) and more powerful (such as in allowing regex searches and keeping track of history), but it’s really a different extension altogether (written by a different developer). On the Simple Context Search, I’ll give it a try when Mozilla allows me to install it on the mainstream Quantum release (I’m using 61.0.2, and when I go to About Firefox to check for updates, it says “Firefox is up to date”)… at the moment, the download page says the extension requires a newer version of Firefox (“at least version 63.0a1”)—does the “a” here indicate an alpha version of the browser? I’m not much fonder of using alpha releases of Firefox to get an extension than I am in hanging onto an ESR version. If I have to dance between using the latest release (61.0.2 at the moment), an outdated version (ESR 52.9) and an alpha version (63.0a1) just to get all the extensions I want, maybe it’s not worth all the trouble. So I pretty much run with the latest Quantum release at home but have to use an ESR for the version we officially use at work (not because of the extensions that I want in particular but for other reasons decided by our IT department).

    2. Peter M wrote on

      Here’s one more:

      Transliterator
      https://addons.mozilla.org/en-US/firefox/addon/transliterator/

      There’s an extension (called “Language Transliteration”) available in Quantum, though, that does something similar, but I like this one better because it’s more intuitive for me and not as much cutting and pasting.

    3. Andrés wrote on

      Session Manager
      Tab Groups
      Suspend Tab
      Classic Theme Restorer

    4. Alex G wrote on

      Advanced Locationbar
      Tab Mix Plus
      Classic Theme Restorer

  21. Paul Polaria wrote on

    If Mozilla lacks the resources, couldn’t they at the very least make a backup of the addons available for archiving or entrust it to an organization which will? Archive.org would be a great place to store them.

  22. Moluk Faczil wrote on

    Since Mozilla lacks the resources, I’m offering to send my old 250GB harddisk to Mozilla (which would be more than enough space for the odd 100GB required) to archive the legacy addons. Please contact me via email.

  23. Max wrote on

    This has been expected for a long time now – but there is a Firefox fork that plans to support most ‘legacy’ extensions indefinitely.

    1. Alex G wrote on

      No, this was not expected.
      What was expected (please see Mozilla press releases):
      1. They will find all missing APIs for most popular extensions (and yes, Tab Mix Plus, session managers are most popular ones);
      2. They wil develop all required missing APIs;
      3. They will work with extensions authors to help them port extensions to new APIs;
      4. Only then drop XUL etc.

      What Mozilla did:
      1. Drop XUL extensions.

      Do you see that steps are somewhat different and some things are missing?

  24. Robert Ab wrote on

    Estimation of the number of Waterfox users based on Mozilla telemetry data: https://www.reddit.com/r/firefox/comments/9bswmn/estimation_of_the_number_of_waterfox_users_based/

  25. JAD wrote on

    Goodbye Firefox. I’m fed up with what used to be a great user experience guiding me in the opposite direction to where I want to be. I need some of the old addons – I am now searching for an alternative browser.

    1. Rixk wrote on

      ‘Pale Moon’ has been my browser of choice since the FF 57 update disabled my important add-ons. I do keep a copy of 52 ESR installed in the rare instance PM has issues with a certain site

      1. scineram wrote on

        How log do you expect those sites to support 52 ESR?

  26. Andrés wrote on

    Mozilla just released the new 60.2 ESR version

    Nobody can delay this train, even if doesn’t work yet. Nice.

    Now my only option is to remain on FF 52.9 ESR to be able to continue working productively (because addons right now are what makes me productive) and just ignore security issues. Very nice.

    Thank you.

    Chrome changed its UI and now it looks ugly. I hope FF doesn’t end up copying that too.

  27. Aris wrote on

    Any ETA about when statistics will be fully migrated from AMO to addons.thunderbird.net?
    Currently addon stats on addons.thunderbird.net are frozen/broken and only show what was cloned on (AMOATN) splitting date. Visiting add-on stats of Thunderbird add-ons only shows endless loading screens. https://i.imgur.com/hD5TXcn.png

  28. Lain wrote on

    Why users can’t choose if they want or not.
    I don’t want a new version or another addon, I want to choose.

  29. Lain wrote on

    classic theme restorer
    No extensions

    noscript classic
    There is a new version, but have a lot of bugs.

    private tab
    There is a extension that let open a new private windown, but I can do it without an extension

    speed start
    there some option, but is not complete like speed start

    status-4-evar
    no option …

  30. sans risque wrote on

    “After legacy add-ons are disabled, developers will still be able to port their extensions to the WebExtensions APIs”

    AS IF PORTING WAS CURRENTLY ALWAYS POSSIBLE! OR PRACTICAL !!!! :((((

    This deadline, like the whole move to a half baked webextension system is totally irresponsible, leave millions of long time users of firefox with poor choices of either giving up on security of usability.

    without addons, firefox would not have NEVER been what it is….

    As a more than 20 years developers, seeing in bugzilla basic functionality bug reports for the webextension that are dragging more than a year proves that this project was totally mismanaged, either in terms of resources, or understanding of the required scope. Either way, while still understanding the incredible resource strain that mozilla suffers, this is still mind boggling.

    Let’s just not pretend that there is a continuity in capability, because that is plain wrong.

  31. Sergey Martynov wrote on

    1) per earlier comments once add-on is disabled the .xpi files are no longer available from AMO. Could it be still available through other distribution channels?
    2) what if the user is on unsupported version with the add-on installed and then updates to the latest after October 2018. Would add-on removed from the browser? How could it be updated to web-extension then?
    Thanks

  32. Roger wrote on

    I am still running 45.9.0 ESR because Mozilla doesn’t know how to build a program and guess what, I have not had a problem since it was released.

  33. Mark wrote on

    I’ve been an FF loyalist and user since FF3.0 and am still on FF56. The sole reason I loved Firefox was the massive customizability of the UX to be exactly the way I want it. Without Tab Mix Plus, Classic Theme Restorer, Session Manager and a few others, FF is worthless to me. I’ve spent a fair bit of time maintaining my old FF56 install and testing a mixture of extensions that all work together and well with it. However, it’s becoming an increasing pain and blocking access to all the XUL extensions is sort of the final FU from FF.

    When my current install next needs maintenance or I have to migrate to a new PC or OS, I’m just going to go to Chrome as FF no longer offers the things I valued about it in the first place and it doesn’t seem like there’s really much intention to ever offer extreme UX customization again. It’s clear many of today’s FF devs see that capability as more of a bug than a feature.

  34. Spartacus wrote on

    This is neither Mozilla nor Firefox.

    You guys are like Opera today. An organization and a browser which try to live from your former – real and honest – glory.

    Fact is you sell out to Google with bringing more and more Google related technology inside the browser. If you really think with offering more of the same what Chrome does offer to lure us Chrome users on board.. I am afraid you are wrong.

    What we Chrome users CAN see is that you sell out. You sell your own advanced technology and power users for us so-called “simple things demanding Chrome users”.

    While it is true, that most of Chrome users are loving simplicity and minimalism, most Chrome users stay away from a developer who sells their own user-base to lure over now a totally different one with different opinion, demands/needs.

    Webextensions and Google translate integrated will not save you Mozilla. XUL and customization had kept you in a quite comfortable place which you have sacrificed.

    If you believe you can reach number one in market share with decisions like these… Think twice. Regards, a happy Chrome user who will never use your Chrome-Firefox hybrid product!