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

Caitlin Neiman

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

38 responses

Post a comment

  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?

    Reply

    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.

      Reply

      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…)

        Reply

  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.

    Reply

    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?

      Reply

  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.

    Reply

    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.

      Reply

      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.

        Reply

  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?

    Reply

    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.

      Reply

  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.

    Reply

    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

      Reply

    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.

      Reply

  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.

    Reply

    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

      Reply

    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.

      Reply

      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.

        Reply

      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.

        Reply

      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!”

        Reply

        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!)

          Reply

      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

        Reply

      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?

        Reply

  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.

    Reply

    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.

      Reply

      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.

        Reply

        1. zakius wrote on :

          I can sign this in blood in needed

          Reply

  8. jore wrote on :

    Fully agree with the very correct views and opinions upstairs.

    Reply

  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!

    Reply

    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.

      Reply

      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.

        Reply

  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.

    Reply

  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.

    Reply

  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:

    Reply

  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.

    Reply

  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?

    Reply

    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.

      Reply

      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.

        Reply

  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.

    Reply

Post Your Comment