The Future of Developing Firefox Add-ons

Today we are announcing some major upcoming changes to Firefox add-ons. Our add-on ecosystem has evolved through incremental, organic growth over the years, but there are some modernizations to Firefox that require some foundational changes to support:

  • Taking advantage of new technologies like Electrolysis and Servo
  • Protecting users from spyware and adware
  • Shortening the time it takes to review add-ons

To help the add-on development community understand how we will enable these improvements, we are making four related announcements today:

  • We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
  • A safer, faster, multi-process version of Firefox is coming soon with Electrolysis; we need developers to ensure their Firefox add-ons will be compatible with it.
  • To ensure third-party extensions provide customization without sacrificing security, performance or exposing users to malware, we will require all extensions to be validated and signed by Mozilla starting in Firefox 41, which will be released on September 22nd 2015.
  • We have decided on an approximate timeline for the deprecation of XPCOM- and XUL-based add-ons.

For our add-on development community, these changes will bring benefits, like greater cross-browser add-on compatibility, but will also require redevelopment of a number of existing add-ons. We’re making a big investment by expanding the team of engineers, add-on reviewers, and evangelists who work on add-ons and support the community that develops them. They will work with the community to improve and finalize the WebExtensions API, and will help developers of unsupported add-ons make the transition to newer APIs and multi-process support.

We’re announcing all of the changes today to make developers aware of our plans and to give everyone an opportunity to offer feedback. We are committed to doing what we can to make this transition as easy as possible. Together with our Mozilla community, we will create the future of Firefox add-ons.

Introducing the WebExtensions API

For some time we’ve heard from add-on developers that our APIs could be better documented and easier to use. In addition, we’ve noticed that many Firefox add-on developers also maintain a Chrome, Safari, or Opera extension with similar functionality. We would like add-on development to be more like Web development: the same code should run in multiple browsers according to behavior set by standards, with comprehensive documentation available from multiple vendors.

To this end, we are implementing a new, Blink-compatible API in Firefox called WebExtensions. Extension code written for Chrome, Opera, or, possibly in the future, Microsoft Edge will run in Firefox with few changes as a WebExtension. This modern and JavaScript-centric API has a number of advantages, including supporting multi-process browsers by default and mitigating the risk of misbehaving add-ons and malware.

WebExtensions will behave like other Firefox add-ons; they will be signed by Mozilla, and discoverable through (AMO) or through the developer’s website. With this API, extension developers should be able to make the same extension available on Firefox and Chrome with a minimal number of changes to repackage for each platform.

A preview release of WebExtensions is available in Firefox 42, which is currently on Developer Edition, and information on how to start testing WebExtensions is available in the Mozilla wiki. We have started discussions with other browser vendors to begin an effort to standardize at least some of this API, and will continue to post additional information and more details about WebExtensions in the wiki.

Multi-process Firefox and Add-ons

Phase one of our Electrolysis project, which uses a separate operating system process to run Web content, has been moving towards our release channel. Subsequent phases will bring multiple content processes and improved sandboxing capabilities. Using a separate rendering process lays the foundation enabling us to bring significant performance and security improvements to Firefox, but it also breaks some add-ons, especially those that modify content. However, there are a number of mitigations in place to keep add-ons functional:

  • WebExtensions are fully compatible with Electrolysis. As the API matures and Electrolysis is enabled by default, this will be the way to port or develop extensions for Firefox.
  • Add-ons based on the Jetpack SDK will work well as long as they don’t use require(‘chrome’) or some of the low-level APIs to touch objects in the content process.
  • Add-ons that haven’t been upgraded to work with Electrolysis will run in a special compatibility environment that resembles single-process Firefox as much as possible. If an add-on touches content, the access will happen via cross-process object wrappers (CPOWs). However, CPOWs are much slower than the equivalent DOM operations in single-process Firefox, and can affect the user experience negatively. Also, some accesses aren’t supported by the compatibility layer and will throw exceptions.

Starting now, add-on developers need to think about their strategy to work with a multi-process Firefox:

The final release schedule for Electrolysis will be determined over the next several months as we test with more users. We would like developers to understand that, although there is a chance that the Electrolysis release schedule will be delayed or modified in the coming months, they should plan to update their add-ons to meet our current release plan as follows:

  • August 11th (Firefox 42 merges to Developer Edition). Electrolysis has been enabled by default on Developer Edition (it is already the default on Nightly).
  • September 22nd (Firefox 42 merges to Beta). Electrolysis will be available to users as an “opt-in” on the beta channel.
  • November 3rd (Firefox 43 merges to Beta). The earliest release Electrolysis will be enabled by default on Beta. When Electrolysis is enabled by default we will begin blocklisting Electrolysis-incompatible add-ons that cause major performance and/or stability problems.
  • December 15th (Firefox 43 merges to release). The earliest release Electrolysis will be enabled on the release channel, and our current planned release.
  • Six months past enabling Electrolysis on Release. The deprecation of CPOWs and compatibility shims will begin. We will release further scheduling information as appropriate, but developers should be aware that any add-ons that depend on them will stop working within six to twelve months of the general availability of Electrolysis.

The Electrolysis team has posted a list of popular add-ons for compatibility testing at In addition to the steps above, developers are encouraged to review the list and follow the instructions to submit information about whether their add-ons are Electrolysis-compatible or not.


We currently use a blocklisting mechanism to defend against malicious add-ons, but additional measures are needed to better protect our users as some add-on developers have adapted to work around blocklisting. Blocklisting is also reactive: users can be harmed by dangerous add-ons that are installed until they are identified and blocked. Starting in Firefox 42, add-on developers will be required to submit extensions for review and signing by Mozilla prior to deployment, and unsigned add-ons cannot be installed or used with Firefox. You can read more about the rationale for signing in a separate blog post.

We realize that the add-on review process can sometimes be inconvenient for developers. Reviewing is a mostly manual, human process today, and moving an extension from the initial submission to passing a full review that meets our guidelines can be a time-consuming process that can take weeks or months. A major advantage of WebExtensions is that they can be reviewed more quickly. In general, it’s easier to develop a correct WebExtension, and the permissions system makes it easier to recognize malicious add-ons.

Our goal is to increase automation of the review process so that the wait time for reviews of new WebExtensions listed on can be reduced to five days, and that the wait time for updates to existing WebExtensions can be reduced to one to two days. Current wait times for unlisted add-ons submitted for signing are less than three days. We are also expanding the team of paid and volunteer add-on reviewers and continue to make improvements to the automatic validator, both of which will reduce existing review queue wait times for all extensions in the immediate future.

While extension signing will not be enforced until Firefox 42, the code has shipped with Firefox 40, allowing users to see if installed extensions have been validated by Mozilla. Users of Firefox Developer Edition will have noticed that unsigned add-ons were blocked beginning on August 14.

The full schedule for add-on signing is currently as follows:

  • Firefox 40: Users will see a warning in the add-ons manager about unsigned extensions, but all extensions will continue to work.
  • Firefox 41: Unsigned extensions will be disabled by default, and Firefox will have a preference (xpinstall.signatures.required) that allows signature enforcement to be turned off.
  • Firefox 42 and beyond:
    • The Beta and Release versions of Firefox based on 42 and above (Beta 42 will be released at the same time as Firefox 41) will remove the preference that allows unsigned extensions to be installed, and will disable and/or prevent the installation of unsigned extensions.
    • The Nightly and Developer Editions of Firefox based on 42 and above will retain the preference to disable signing enforcement, allowing the development and/or use of unsigned add-ons in those versions. Unbranded versions of Firefox based on releases will also be made available for developers, and are expected to be in place for Firefox 42 for release (and potentially beta).

Deprecation of XUL, XPCOM, and the permissive add-on model

XPCOM and XUL are two of the most fundamental technologies to Firefox. The ability to write much of the browser in JavaScript has been a huge advantage for Mozilla. It also makes Firefox far more customizable than other browsers. However, the add-on model that arose naturally from these technologies is extremely permissive. Add-ons have complete access to Firefox’s internal implementation. This lack of modularity leads to many problems.

A permissive add-on model means that we have limited flexibility in changing the foundations of Firefox. The add-on breakage caused by Electrolysis is an important example of this problem. Technologies like CPOWs help us to work around add-on problems; however, CPOWs have been a huge investment in effort and they are still slow and somewhat unreliable.

Without a fundamental shift to the way Firefox add-ons work, we will be unable to use new technologies like Electrolysis, Servo or browser.html as part of Firefox.

The tight coupling between the browser and its add-ons also creates shorter-term problems for Firefox development. It’s not uncommon for Firefox development to be delayed because of broken add-ons. In the most extreme cases, changes to the formatting of a method in Firefox can trigger problems caused by add-ons that modify our code via regular expressions. Add-ons can also cause Firefox to crash when they use APIs in unexpected ways.

Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now. We are announcing the change now so that developers can prepare and offer feedback. Add-ons that are built using the new WebExtension API will continue to work. We will also continue supporting SDK add-ons as long as they don’t use require(‘chrome’) or some of the low-level APIs that provide access to XUL elements.

A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible.

Moving forward

The strategy announced here necessarily involves a lot of trade-offs. Developers who already support Chrome extensions will benefit since they will have one codebase to support instead of two. Developers of Firefox-only add-ons will have to make changes. Those changes may require considerable development effort up-front, but we feel the end result will be worth that effort for both Firefox’s users and developers.

We want to reiterate our commitment to our add-on development community, and will work with you in porting extensions, designing new APIs, and creating innovative new add-ons that make Firefox great.

We will continue to post additional resources in the coming weeks and months to outline each of these changes in more detail, as well as provide support through our traditional channels via the Mozilla Developer Network, IRC (in #extdev), and the extension developer group.

Update: A lot of people have been asking what WebExtensions will deliver, and how. Bill McCloskey has posted an update on where we want to take them, and how you can contribute ideas and be part of the process. It’s a must-read for people who are concerned about how the addons they develop, use, and love will continue to be part of Firefox.

Update: We’ve added a Frequently Asked Questions section to the WebExtensions page, and will continue to address feedback and questions there along with additional posts in the near future.

471 comments on “The Future of Developing Firefox Add-ons”

  1. John wrote on

    Great move!!

    1. Noitidart wrote on

      I think it’s a great move if we add it as third option, alongside, calssic, addon-sdk, and this. This way devs that are users of other browsers, and just want to support Firefox, can easily do so. And this will also make it easy for the new kids to make addons.

      I like this as long as we can still do what we could in the past. I like the idea of moving from XUL to HTML, im willing to rewrite. I actually was doing stuff in xhtml files anyways, love the dtd localization support for it, its insanely fast, much faster then the javascript i18n method. I used XUL/XBL only when modifying browser chrome of firefox.

      I think XPCOM is some pretty performant stuff, but if we can do the same thing from threads I would be cool with rewriting it, but some stuff like some js-ctypes needs to happen on certain threads. I’m hoping in the new design it’s possible to set up callbacks on the main thread from js-ctypes, that would solve all issues of the multi threading. Right now we had some issues with callbacks on main thread from js-ctypes:

      Same situation when trying to use dispatch_get_main_queue and dispatch_async for OSX:

      So as long as js-ctypes stays, Im cool with XPCOM going away, because I think we’re in the right direction to get into XPCOM from other threads with js-cpp-types 🙂

      I’m just real worried about losing the old methods, because that had so much creativity, with the new API, if a module for doing X doesnt exist, then we can’t use our engineering skills and create a solution. I love that about today, lots of things can’t be done, but with our eng skills we can pull it off 😀

  2. antoyo wrote on

    How much time does it take to get an add-on hosted on AMO to be signed?
    My add-on, Auto-Sort Bookmarks, has been fully reviewed on august 6 and august 13, but these versions have not be signed.
    Thanks for your answer.

    1. Jorge Villalobos wrote on

      Every version is signed after passing review. Maybe you’re confused because when we auto-signed existing extensions we appended a .1-signed to the version number. That only happened once, and new versions don’t get that treatment. However, they are all signed as soon as they pass review.

      1. Anonymous wrote on

        Yes, the “.1-signed” versioning was very sloppy and confused many people. Users still contact developers worrying the new versions are not signed. AMO somehow managed to fundamentally break this basic system by adding a word into version numbers…

  3. Anonymous wrote on

    > Deprecation of XUL, XPCOM, and the permissive add-on model

    Permissive addons are what sets firefox apart. It allows creative use, even interfacing with native code in ways nobody predicted.

    Addons that can only use “approved APIs” basically are chained to whatever mozilla developers think might be useful. No outside-the-box thinking.

    Even jetpack provides ways to break out of its constraints precisely because its APIs often are insufficient.

    1. TobiSGD wrote on

      Absolutely. The main reason at this point for me to stick with Firefox is its great extensibility, which allows extensions like Pentadactyl or Vimperator to offer functionality that no other mainstream browser can deliver. If Mozilla gives this up for a dumbed down interface just to be Chrome compatible then this is the end of me using Firefox and I have to go for a niche browser like vimb or dwb instead.
      Sad news, Mozilla, sad news.

      1. mccr8 wrote on

        The goal of this change is not to be more compatible with Chrome. The goals, as described in the blog post, include making it so that addons can be written that work well with multiple processes (which is essential to improving the performance and security of Firefox). Chrome just happens to have a well-tested addon model that supports multiple processes, and that many addon developers are familiar with.

        1. Connor Behan wrote on

          It’s well tested and the test results that have come back are this: it doesn’t allow users to do very much with the browser. Fixing everything for e10s may be needed but there is no need to adopt a new addon approach where 90% of the things that used to be possible no longer are. I really hope coders find ways around this. There is already no reason to use official Firefox builds. First they rejected shared libraries in favour of their own bloated ones. Now this.

        2. Will wrote on

          And Mozilla just happens to be explicitly copying that model so that Firefox will behave more like Chrome. From the post:

          “we are implementing a new, Blink-compatible API in Firefox called WebExtensions. Extension code written for Chrome, Opera, or, possibly in the future, Microsoft Edge will run in Firefox with few changes as a WebExtension”

        3. Josh wrote on

          I like this idea to allow people to install Chrome extensions, but please don’t destroy the ability for extensions like Pentadactyl to work. That’s why Firefox is great and Chrome is not. I would have to stop using Firefox if the ability to customize it is removed or reduced.

          The new search box sucks (TAB doesn’t move to the next item, but chooses search engines that I don’t use) and I need Pentadactyl. Otherwise the interface is unbearable. About:config is another area that shouldn’t be tampered with.

          Good move: make Chrome extensions run on Firefox
          Terrible move: remove functionality from Firefox that your core supporters depend on

          1. Noitidart wrote on

            Gotta use the up/down arrow keys to move through search suggestions, and tab/shift+tab (or left/right arrow keys) to move between engines, i kind of like it, it gives all the arrow keys functionailty in that box. But it is a very keyboard-centric thing.

          2. Josh wrote on

            The change in those keys has been terrible for me. I’ve been using Mozilla/Firefox for over 10 years and I don’t want to be forced to change keybindings that are deeply embedded in muscle memory. All they would have to do regarding that problem is to put a switch in about:config to let me change it back, and I would be happy.

            I have an extremely fast system of operating the computer with keystrokes by feel, and that unwanted change in keybindings constantly throws a wrench in my system. It’s like being forced to visit by typing “” into Google and then clicking the first result. (I’ve seen people do it.) The new keybindings are painfully slow to me in a similar way.

            Also, it causes UI inconsistency, because ctrl-L puts you in a box where tab moves down the list, but ctrl-k requires you to move your hands off the main keyboard to use the arrow keys. It’s slows me down when working at high speed, because I work from muscle memory.

            In the meantime I have Pentadactyl to override the ctrl-k box, but if that gets taken away, using Firefox will become very frustrating. Pentadactyl is consistent — it doesn’t matter whether I press ‘o’ or ‘w’ or ‘t’ — I get the same behavior for all three with TAB completion. If I accidentally push the wrong button, I can continue with the next instinctive keystroke (TAB), and I’ll still get to where I want to go without having a pause wondering where my cursor is.

  4. David wrote on

    This post isn’t as clear as I’d like about the future of the Addon SDK. Is it deprecated? No longer being invested in? Will be maintained for more than 18 months, but no more features?

    For politeness reasons, I think it’s important to make it really explicit how the SDK should be understood (being coy isn’t being gentle).

    1. Kev Needham wrote on

      There are no plans to deprecate the Addon SDK in its current form at this time. It’s already Electrolysis compatible (although, per above, the use of require(‘chrome’) will not be supported). However, we expect that most of our effort will be directed towards extending WebExtensions to meet developer’s needs. Some of these APIs may be ported to Jetpack as needed, but WebExtensions will be our favored platform.

      1. David wrote on

        As someone who has 4 SDK based addons on AMO, that sounds like a weak stance, and one that’s not actually going to make friends.

        There should be a single focus – making WebExtensions support all the things that addon-authors need, and providing tooling around them.

        If the Addon SDK isn’t part of that, you should declare it deprecated and tie its end to the end of other current Addon types.

        Keeping it around until its only used for the most powerful 10% of addons, then pulling the plug is just going to cause this pain all over again.

      2. Wladimir Palant wrote on

        So, another “let’s rewrite all extensions” call? Frankly, I’m getting tired of this game. Yes, XUL/XPCOM aren’t a stable API. But it betting on stable APIs doesn’t seem to make matters better. FUEL? Deprecated. Add-on SDK? Going to suffer the same fate judging by your comment. I understand why FUEL had to be replaced. But I don’t see why another extension API has to be developed in parallel to the Add-on SDK which already took tons of effort to become usable.

      3. Lovo wrote on

        It would be a waste to freeze the SDK, especially since it still offers a path to graduate new APIs (whereas the only option for WebExtensions is: patch firefox, a huge bar), offers functionality that isn’t in Chrome, and offers a lot more than the very bare chrome subset described on the wiki (and even that is half-implemented as of this writing).

        Please at least give SDK add-ons access to the new APIs so we can reduce transition pain.

  5. Will wrote on

    The main reason I use Firefox over Chromium (or a less popular alternative like Opera or Konqueror) is that it supports greater user freedom by allowing me to customize the browser the way I want through add-ons (whether developed by myself or by someone more capable). My reading of this announcement is that Firefox add-ons will now be no more powerful than Chromium ones. There will be some performance improvements that come with this change, but if that were my primary concern I probably wouldn’t be using Firefox. This customizability feature was the one I was clinging on to as my main selling point for using and advocating use of Firefox. There will always be tradeoffs between customizability, stability, performance, and security. So I am curious, once all of these changes are implemented, how do you (anyone familiar with the upcoming changes who wants to reply) plan to present Firefox as the best browser choice?

    What is the future of the Add-ons SDK? It’s not very clear from the post, but the tone I take away is that, just as XUL extensions were supported after the SDK was introduce, the SDK will continue to be supported for the present but will eventually be deprecated in favor of WebExtensions.

    “When Electrolysis is enabled by default we will begin blocklisting Electrolysis-incompatible add-ons that cause major performance and/or stability problems.” I hope that good judgment is used in these cases. I can understand wanting to block a formerly popular add-on that it still widely deployed but causes Electrolysis-enabled Firefox to crash frequently. In general though, I hope that extension signing is not used to prevent novice add-on developers from using their own, possibly poorly written add-ons.

    A couple of add-ons that I use and am worried might not make it through all of these changes: Zotero and Pentadactyl/Vimperator.

    1. k wrote on

      I can only operate my computer with my left hand, and vimperator / pentadactyl make it so much easier to navigate and participate online. I truly hope this functionality won’t be broken or require that I run an unstable developer browser.

      I don’t personally understand the value of a the add-on signing requirement. If a bad actor’s code is running on a user PC they can circumvent the check so many ways and keep their add-on working, or just move to something more obscure and hard to remove to do their ad infection or whatever.

    2. Lee Hyde ( wrote on

      If the developers at Zotero can’t work with the new framework, I do hope they opt to fork Firefox to create a stand-alone bibliographic browser. I never really understood the utility of their standalone client with the browser stripped out, and I’ve often wanted to run Zotero in a separate firefox profile to my standard profile, but it’s awkward to set up and run two profiles in parallel if memory serves. I certainly hope they don’t just pack it in.

      IANAD but are these changes really that restrictive? Is there no scope for improvement beyond the woeful Chrome model? What would be the implication of WebExtensions and scrapping XUL entirely in favour of a HTML5/JS/CSS3 chrome (as I seem to recall some Mozilla bigwig blue-skying afew weeks back)?

  6. Anonymous wrote on

    Have you considered the fact that there are no alternatives to firefox before trying to kill it this much?

    1. Connor Behan wrote on

      Exactly. This has been a long time coming with increasingly bad decisions. It will always be important to run our own code or code shared by colleagues before it’s been cleared by an overlord. So making a custom build with “xpinstall.signatures.required” will now be my advice to everyone. It’s already been good advice for some time since official builds cater to the lowest common denominator by rejecting shared libraries in favour of bundling 100 of MB of bloatware.

    2. LimboSlam wrote on

      There are alternatives to Firefox, it’s that they are following specifically every move Mozilla makes for better or worse without thinking; how it will impact their users everyday browsing, especially add-on devs who are the ones that make Firefox flexible in every way. This is also why I’ve switched to Pale Moon and so have others, yeah it’s true. Actually, just recently someone here has read this and says he’ll be stinking with us because this was the last straw for him.

    3. Rob wrote on

      There is Pale Moon!

  7. Alfonso wrote on

    I guess that by removing XUL extensions you’ll kill Classic Theme Restorer and force everyone to use Australis, right?
    And this way Firefox will finally achieve its long term goal of fully being a Chrome clone, good job Mozilla.

    1. Kev Needham wrote on

      Classic Theme Restorer is an add-on a lot of people like, and Themes are a part of Add-ons that we’re looking at. The ability to personalize Firefox is what add-ons are all about, and something we want to retain; how we enable themes to do what they do now simply and safely and without needing to go deep is one of the problems we need to solve. It’s too early to make any promises around themes, but it’s an area I’d like to see us provide differentiation.

      1. Yourecrazy wrote on

        If you cared about personalization, you wouldn’t be restricting add-ons like you are. You’re killing it for the sake of forcing your own curating to it so you can control what your users can do. And thus, you eliminate any reason at all to use your browser over the competition

  8. Anonymous wrote on

    I sure am excited for my favourite browser to become a Chrome clone!

  9. Will wrote on

    This is off-topic to add-ons specifically, but I haven’t seen a timeline posted previously for the deprecation of XUL. Such a change would be made at the Gecko level, right? So does this announcement have major implications for other Gecko based applications like Thunderbird and Seamonkey?

    1. Jorge Villalobos wrote on

      There is no clear timeline for this yet. It’s a very big change that will probably take a very long time. Support for XUL extensions is something that can be done more quickly, though, which is what the 12-18 month estimate is about.

      Thunderbird and SeaMonkey are already behaving closer to ESR, making less frequent releases and not depending on the very latest code. This decision does affect these applications if their developers intend to continue using the Firefox codebase as their foundation. But, again, there’s plenty of time before this happens.

  10. Berndo-kun~ wrote on

    >We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.

    Well, that’s nice. Migrating away from Firefox will be as painless as possible. I hope Google sends them a cake once they’re below 5%.

  11. Alfonso wrote on

    BTW, if you really want to show us that you trust this much in these new WebExtensions, the first ones to appear at AMO should be Pocket and Hello.
    Remove that code from the core Firefox and put it where it always should have been: an extension that anyone interested can easily install.

    1. Aris wrote on

      Will “WebExtensions” allow user interface modifications of toolbars, buttons, colors, item order etc. ? I’m asking, because Google Chrome does not allow to modify anything when it comes to the ui (except changing toolbar background with images like Mozillas Personas/lw-themes).

      If we won’t be able to modify the user interface, there would be absolutely no point in using Firefox in the first place. Please remember why users and developers are using Firefox. If we would want to use Google Chrome, Opera or Internet Explorer (Edge), we would use it.

      1. Bill wrote on

        Absolutely. Mozilla seems to be increasingly losing sight of why people choose to use it.

  12. Anonymous wrote on

    Powerful addons are Firefox’ superpower, allowing it to punch way above its weight.

    Removing the permissive addons model is pure Kryptonite. It will limit innovation.
    It’s precisely the long tail that nobody is ever going to design an API for that matters in the aggregate.

    If you are lucky, you may end up with a more stable ecosystem, but it will be less diverse and exciting, and no reason to switch to Firefox for.

  13. Kartik Agaram wrote on

    > Add-ons based on the Jetpack SDK will work well as long as they don’t use require(‘chrome’) or some of the low-level APIs to touch objects in the content process.

    I maintain a private but open-source RSS extension for myself which uses require(‘sdk/chrome’) for access to firefox’s html parser and bookmarks. It doesn’t modify existing pages except to open new tabs. Are its days numbered? Will I be able to continue using it in the unbranded release?

    1. anny wrote on

      The point of this blog post is to ask people like you to contact them with information and opinions on what the new API will should look like.

      For example you should send them an e-mail saying:

      I currently use require(chrome) for the html parsing and bookmarks features. I think the new system should make these available individually. Example: require(html.parser); require(; require(bookmarks.create); require(;

  14. Nils Maier wrote on

    I was thinking of abandoning add-on development for a while now, mostly because of the Walled Garden signing approach that went live, which I strongly objected to and still strongly object to… I might have come to terms with it, once I see it play out in an actual implemention…

    But “deprecating” XUL-based add-ons with XPCOM access takes the cake. Once that happens, I will abandon ship for sure. Simply because I cannot continue developing most add-ons at all as they will not and cannot fit into any “WebExtensions” API. The flexibility of what XUL-based add-ons can do IS the major selling point of the Firefox add-ons ecosystem and therefore IS one of the last remaining selling points of Firefox itself that isn’t purely ideological. In comparison, the APIs that Chrome and competitors offer, that the Firefox Jetpack/ Add-on SDK offers, are just… toys.

    To give a little background about myself to show that I’m not just the random hater shooting a drive-by comment: I wrote some more or less successful add-ons in the past, including DownThemAll!, and reviewed many, many add-ons as an AMO volunteer.

    1. Anonymous wrote on

      Based Nils.

      Mozilla, why not provide a choice of enabling these features as a separate package installation? Surely it is possible to provide for this architecturally; i.e. a Firefox running electrolysis with certain processes given access to XUL through a translation layer.

      Where is Firefox once it alienates the power users and developers?

    2. Nils Maier wrote on

      For reference, I took the very unusual (for me) step to blog about this on

      It surely has some pathos in there, but then again, I’ve seen the Chrome APIs, used some Chrome extensions that were supposed to be “replacements” for Firefox extensions, seen the JetPack/Add-on SDK project(s) from the start and how that turned out… and therefore cannot shake feeling deeply and truly pessimistic and sad about the “No more XUL add-ons” announcement.

      1. Anonymous wrote on

        Someone will hopefully understand the scope of this confusion quickly, and walk this back. Announcing a mandatory transition to a WIP API is a good way to kill Firefox completely. Some stuff is long overdue for restrictions; addons can do too damned much. However, it would be significantly more viable for Mozilla to create a whole new browser than to drop all XPCOM & XUL support for addons. The entire community would collapse. It isn’t even possible unless you enter the fantasy would where addons only support the current version, and even then, I don’t think it’s realistic. If the goal is to avoid breakages on new versions, this is the OPPOSITE of what’s needed. This would be the ultimate breakage on new version, and will not be fixable by many.

        1. Will wrote on

          I have the opposite view. I don’t think add-ons do too much. Firefox has been around for a while and has undoubtedly acquired a fair amount of cruft, so reworking the rendering engine to use HTML instead of XUL could be an opportunity to refresh and improve the codebase. Severely limiting add-on functionality is not required by this change though. It seems like this major disruptive change to how Firefox renders itself is being used to also majorly change the way add-ons work (I am sure there are many core developers that have wanted to handicap add-ons for years), and that’s the part that disappoints me. I’d be okay with breaking all add-ons with major changes to Firefox if those changes made it a more performant and secure browser but allowed it to still be customizable. Removing the ability to customize Firefox with add-ons though just makes it not the Firefox that I loved any more.

          1. Oceinic wrote on

            Firefox sometimes conducts user surveys. I believe before they unveil plans to remove ZUL they had to make a survey with the following question.
            Will you continue to use Firefox if the following addons will stop working?
            And list currently installed add-ons containing “`require(chrome)“`

      2. Anonymous wrote on

        @Nils Maier, I know how you feel! So I suggest you make the switch to Pale Moon as I have heard they are not a Firefox clone, but a fork that is and will support XUL and XBL code for making extensions.

        1. Riik wrote on

          So you have heard. Annoying spam.

          1. Jacob Hill wrote on

            @Riik: I know you may be standing up for Firefox (I was too at a point) and don’t want to believe the hard truth, but Pale Moon is actually a pretty good browser, for it being based/fork off an old Firefox and the lack of add-on compatibility. Though I’m sure they will get a handle on it as more and more devs come around. Also, I’m actually using their Pale Moon as I type to see if these so called rumors are true, or just as you say spam. And to be honest it’s quite smoother and very memory efficient. They also do support XUL, XPCOM and XBL as they say: So does this mean I’ll be using Pale Moon, I don’t know.

            But it’s just my opinion/ovulation and I do know this isn’t everyone’s cup of tea, so the decision is up to, either believe the what others are saying is “spam” and criticize this browser all you want, or check it out for yourself and then you can say it’s truly spam (if that is what is).

            **NOTE:** Pale Moon Users, please don’t spam off-topic here. If it’s any good and stands on its own two feet, then you have nothing to worry about. But for the love of Russell’s Teapot, take your advertising elsewhere. Thanks!

          2. riik wrote on

            @Jacob: I acknowledge the existence of Pale Moon and I don’t doubt its goodness. But aren’t addon devs self capable of looking for alternative browsers?

            Personally, I wish that if Mozilla thinks that the technology of Firefox is at its end a completely new browser with the new technology sharing the same ideologies with Firefox is made. Of course, if the same ideologies are not followed it will mean the end of me using Mozilla products altogether.

      3. MV wrote on

        Firefox wants to go down like Opera.

    3. Patrick Cloke wrote on

      Nils, thanks for writing this (and all your great add-ons over the years!), I couldn’t have said it better myself. But just to reiterate:

      This is *THE* differentiating factor of Mozilla Firefox at the moment. Without this, there is *NO* reason (besides ideology) for people not to use competitors. I doubt most people use Firefox for Mozilla’s ideology, but having those users gives you more clout.

      Seems like a slap in the face to the add-on authors who have put blood, sweat, and tears into helping make Firefox into a browsing experience that can be personalized.

      I’m extremely disappointed in this decision. It seems like another blunder for Mozilla in the past few months; another way to alienate users.

    4. Noitidart wrote on

      Dude you can’t quit addons man. You have a positive impact! You taught me everything I know!

  15. Charles wrote on

    Your post mentioned taking advantage of Servo, but I thought Servo was just a research project. What do you mean? In what way will Firefox take advantage of Servo?

    1. Yuhong Bao wrote on

      They are going to switch to it as the rendering engine most likely in years, and it will not support XUL/XPCOM

  16. Gabriel Ivanica wrote on

    Oukey… So it took me at least 6 months to understand how to build XUL overlays using Addon-SDK, even compatible with E10S, and now you’re telling us that we won’t be able to do that… Ok I do understand that using require(“chrome”) is dangerous but at at the same time is very powerful and can bring back a lot of features that were obsolete when Addon-SDK came out. Firefox without it’s powerful customization is nothing. Really now? I don’t want to live in a world where addons are justsome simple stupid panels that do almost nothing because they must be cross-browser compatible. I’m an addon developer and I personally don’t care about other browser. There are some that do but that’s not the point. The point is that I want the power to change the UI as much as I’d like, to do things that other browsers won’t ever permit because that’s what Firefox means.
    I do understand that there are security concerns but isn’t that the whole reason why we have a team of addon reviewers?
    Firefox is all about the customization and the power it gives you to make your browsing experience how you’d like. Take that, and there you go… A shinny browser that does nothing more than it’s competitors.

  17. MoSal wrote on

    I concur with the commenters who mentioned Vimperator/Pentadactyl.

    A lot of us advanced users wouldn’t be using Firefox today if it wasn’t for those excellent add-ons. It would be a real shame if they could no longer work. Or could only work in a limited capacity similar to their inferior clones written for Chrome.

  18. Anonymous wrote on

    Bullshit. Why take out what made Firefox unique? This isn’t what the users want.

    1. T. S. wrote on

      Taking the decisions being made since some time, since when does Mozilla care about what users want ?

  19. Connor Behan wrote on

    A different style of addons isn’t the reason why people are leaving Firefox. It’s the reason why some people are still using Firefox. I know forcing developers to rewrite addons is inevitable in order to benefit from e10s. But ditching your entire approach to addons in favour of a locked-down Chrome-inspired model, where even Adblock has trouble, is a big mistake. I’m counting 21.276 addons that need to be rewritten. How many of them do you think are actually going to bother?

  20. Alex wrote on

    In all these discussions about developers you are forgetting about the users.

    It may surprise you that Firefox is used not only by developers but also by people that want to view and interact with web sites in ways that are convenient to them.

    The reason that I use Firefox — the ONLY reason — is because it has several extensions that simplify my online life. Many of these extensions are no longer actively developed or supported, likely because the people that wrote them did not consider life-long maintenance to be their calling, but they still work and do what I need them to do.

    The ongoing changes to Firefox feel like they are motivated by a desire to force the users to use the Web as Mozilla envisions and not as they want or need to. First we got Australis shoved down our throats and only Classic Theme Restorer managed to somehow mitigate that disaster (by the way, the fact that it is currently the highest rated extension on AMO with a number of daily users approaching half a million, should tell you something), now we have forced signing (but at least I will be able to use the unbranded version) and soon you’ll break most of the extensions that still keep me on Firefox by killing XUL.

    When that happens, what reason will I have to continue using a browser that does not do what I want it to do?
    Moreover, what reason will I have to stick with a browser that insists on repeatedly breaking the way I use it and forcing me to spend time, effort and frustration on retraining myself only to go through the same process again and again?

    I used to recommend Firefox to everyone. Hell, I used to advocate it and actively try to persuade people to switch to it. I don’t do that anymore, and when asked just say “just use chrome, it works and it’s predictable”.

  21. Will wrote on

    Does this mean XUL support will be stripped from the underlying Gecko engine in the next 18 months? Does this announcement have implications for Thunderbird, Seamonkey, etc?

  22. anon wrote on

    this is pretty much the death knell for firefox, a self-imposed destruction.

    firefoxes only advantage is(was) the empowering of users to make their own choices, and the power of its extensions. by taking both away it you make it another 2nd rate browser where other people get to make all the choices.

  23. Blank wrote on

    This is very disappointing. WebExtensions is not a replacement of XPCOM/XUL APIs, it’s a new model that is fundamentally different because it severely limits what add-ons can do.

    Currently, Firefox is the only browser that is able to be extended with powerful add-ons like NoScript, Vimperator or Find Bar Tweak. Taking away the current level of low-level customization and instead replacing it with WebExtensions will not only kill many add-ons that will now no longer be able to exist *in any browser*, but it’ll also stifle innovation. I’m sure many of the new APIs will be based on existing popular add-ons, but if Firefox had adopted a model like this since its inception, many of them would have never been created.

    It also seems very inconvenient being forced to use a different release channel just to be able to use unsigned add-ons.

    I’m sure you are reasonable and understand the feedback you’re receiving, so please reconsider some of your choices.

    1. Curtis Kwong wrote on

      NoScript is awesome security add-on 🙂

      Fact about the ScriptSafe add-on (Chrome) – fake security

  24. Chris Rosenau wrote on

    Firefox keeps making decisions without listening to the user base. You did this by just following Chrome’s lead and mimicking their interface and by removing the status bar. Then you added Pocket which should be a plugin instead in the code. Then you FORCED us to not use Flash. Now you are going to destroy the addon community. THE ONLY REASON I USE FIREFOX OVER CHROME IS THE ADDONS. You waste time on copying other browsers instead of being innovative. If you are going to copy something, copy the chrome mobile tools. Where the hell is the 64bit version.

    Next thing we know you will be switching to webkit.

    Some needs to fork Firefox and breath life back into it.

    1. Josh wrote on

      These comments are making me nervous. If Pentadactyl doesn’t run on Firefox in the future, Firefox will become unbearable. The UI changes over the past few years have been terrible, and Pentadactyl is the only thing that fixes it.

      1. Tensy wrote on

        I just download Pale Moon and the Pentadactyl add-on is available for it.

    2. Anonymous wrote on

      Switch to Pale Moon (a fork)!!! They will keep support for XPCOM, XUL and XBL source code for any add-on devs that wish to use it.

  25. Ngamer01 wrote on

    So it’s finally happened. Mozilla has completely gave up on innovating. So when the announcement comes that Mozilla is dropping Gecko/Servo and adopting Blink/Chromium, I won’t be surprised. I also won’t be surprised if Mozilla locks this blog post for people not blindly following them.

    I’ve been a fan of Firefox since Firefox 1 due to the vast amount of customization thanks to extensions and complete themes. If the new DRM that is coming happens, all of my favorite extensions and themes will die or move to other platforms like SeaMonkey.

    Looks like Mozilla is going to enjoy its Windows 8 phase…and its results like Microsoft got (people refusing to upgrade or moving to other platforms). We can only hope Mozilla wakes up and starts giving us the Windows 10 treatment Microsoft is giving users (minus the privacy woes).

  26. D P wrote on

    This post really marks the final end of Firefox. The end of a truly robust Add-On model is the only thing remaining at all that sets Firefox apart. The Foundation’s constant running after being a Chrome-alike has finally run the browser into the ground fully.

    Hopefully, from the ashes, one of the custom builds (Palemoon, etc) can raise from the ashes and, once again, be the new browser reborn. Perhaps this time it will be run competently by an entity that doesn’t censor dissent with moderation, eliminate EACH AND EVERY listed principle and guideline the browser had set for itself and become a pale shadow of its former self.

    1. alex wrote on

      If there had been a “truly robust Add-On model”, this change wouldn’t be necessary.

      1. Anonymous wrote on

        And you know what? This change IS unnecessary. There is no way to retain all the power Ff addons have now in restricted “WebExtensions” environment. Either “WebExtensions” API should allow everything current XPCOM/XUL allows, and it will be in the same “security field”, or Ff will be just another poor clone of Chrome. And no, thanks, i know where i can download genuine Chrome already.

  27. Bob Anonmous wrote on

    As someone who develop an addon for FF and use the browser as my only browser I’m sadden by this turn of events. I don’t make money from my addon and tbh I’m not going to put the effort in building a new addon using the webapi when there’s no upside to me. History shows again and again that when a piece of software breaks compatibility it usually ends up dying. Chances are this is the end of firefox, mozilla has shown over the last 4 years that they have a problem with implementing chances and listening to the community. There’s bugs in FF that have been documented and left open for years so I doubt that you’ll be able listen to the community and make webapi robust enough to do everything xul can before you depreciate it. This means that firefox addon devs will be thrown under the bus while chrome dev will have a hell of an advantage. Why would the end user want to use firefox if it’s exactly like chrome.

    Good luck, you’re going to need it.

  28. David wrote on

    There’s mention of a bulked-up team for AMO. Is that the case for implementing new WebExtensions APIs? If you could talk about a team which you’ve committed to for a year or more to expose truly powerful APIs, that might help.

    eg. A WebExtensions version of ServiceWorkers that can do what ServiceWorkers can do, but across domains/tabs would be incredibly powerful, based on web standards, and fit into a modern browser architecture.

    It *might* need additional review, but when extensions can change what a user sees eg by CSS, they’re incredibly powerful already.

  29. JohnnyCee wrote on

    The ONLY reason I prefer Firefox is its customizability. I want to control what the browser looks like and how it acts, and if that is lost, I might as well use Chrome.

    Do not restrict add-ons from the scope they have now. If necessary, force add-ons to ask for permission to access browser internals, and put the onus on add-on devs to keep up to date with internal changes.

  30. Linus wrote on

    “We have decided on an approximate timeline for the deprecation of XPCOM- and XUL-based add-ons.”

    goodnews for firefox forks

    1. Gecko User (All kinds) wrote on

      Yes it is, one of my personal favorites is Pale Moon!! Second would be Avant. You, know I was going to give an little summary on both on them (Pros and Cons), but seeing how this is advertising now, I will leave it up to you Firefox/Gecko users to decide for yourself which will be your perfect fit.

  31. Tom wrote on

    Why would you force thousands of add-on developers to learn a new programming construct, and force all of them to completely redesign their add-ons?

    Two of the best features of Firefox, for me as a user, are memory management and a huge list of add-ons to choose from.

    For example, Firefox can have hundreds of inactive tabs and say, 5 active tabs, and still use less memory than Chrome with only 3 or 4 active tabs.

    I hope that the new version of FF allows tabs to be modified by developers.

    And I hope that the developers of my favorite add-ons (and there are many that I use daily) are willing to redesign their add-ons based on your whims.

    Oh, I get it. You must have hired the former Microsoft management that created Windows 8!

    Kudos for killing Firefox.

  32. Alexander Gieg wrote on

    Netscape: September 1994 – February 2008

    Firefox: September 2002 – February 2017

    Pale Moon: October 2009 – ???

  33. Lohl In Ternet wrote on

    I look forward to seeing Pocket and Hello ported to using the WebExtensions API.

  34. Anthony Lieuallen wrote on

    As a maintainer of one of those “many Firefox add-ons [which] cannot possibly be built using either WebExtensions or the SDK” (Greasemonkey): How exactly are you going to “seek feedback from the development community”?

    I’ve got over a milion users. I’ve wasted a lot of time trying to be e10s compatible, accomplishing almost nothing else in the past ~9 months. Now you tell me that within another 12, you’re going to make it even harder to keep my feature set functional for my users?

    Please contact me via email. My address is easily discoverable from my name, and you’ve got the private one I pasted above, too.

    1. Anonymouse wrote on

      Oh, don’t worry, they’re going to “seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible.” I’m sure they’ll ensure Greasemonkey works (*heavy sarcasm*).

      I see dozens of posts here pointing out the same thing: this is the death knell for Firefox. Absolutely no replies from Mozilla, either. The decision is made, and they couldn’t give a darn.

      Do they think we use Firefox for the BRAND? We use it for the ADD-ONS. WHY AREN’T YOU LISTENING????

    2. ZXSpectrum wrote on

      Efforts to comply with E10s compatibility in current development scheme and/or moving to SDK are giant waste of time now.

    3. Noitidart wrote on

      Dang man. Everyone else’s frustration I couldn’t understand, because this blog post was just a blog post to get a feel from feedback.

      But even just being a feel out blog post, for you to have put in 9 months for e10s and then just someone mentioning the possibility it’s going to go away is a slap in the face.

      Everyone else I don’t understand, you I do though. I’m sure they won’t get rid of it, so I’m replying to you just to give you a motivational boost. Don’t lose faith! Firefox is the Firefox we love! They won’t abandon you! Hang in there!

      1. Anon wrote on

        > Firefox is the Firefox we love!

        Firefox team has been working really, really hard lately on changing that.

      2. anonymous wrote on

        >Firefox is the Firefox we love!
        And yet they try to make me hate Firefox with all of their recent decisions?

  35. Tom wrote on

    Wait, so this change is gonna kill Greasemonkey?

    Aw, shit. That’s all I can say.

    1. Josh wrote on

      If it kills extensions like Greasemonkey and Pentadactyl, then it’s definitely a bad idea. I hope that someone from Mozilla has sense to understand the negative feedback here.

      I’m worried, because no one listened to the negative feedback here either, and it’s still a problem:

      That issue still isn’t resolved, which is why Pentadactyl is the only workaround for me.

      If Mozilla makes people rewrite all the add-ons the end result will be very few add-ons that one can’t find on other browsers. If every add-on and feature that I use existed for Chrome, there would be fewer reasons for me to use Firefox. Chrome doesn’t have Pentadactyl or the privacy extensions that Firefox has, so I use Firefox. If those disappear and all Firefox extensions just become afterthoughts of the Chrome versions, then this could be the final moved that kills Firefox. Please don’t do that.

      1. Jorge Villalobos wrote on

        Give this blog post a read and send it to the developers that you think will have their add-ons break with this move. We want to get as much feedback and ideas as possible so that WebExtensions support as many extension types as possible.

        1. Emiliano Heyns wrote on

          The blog post is great news for Giorgio, but of no use for most of us. I don’t see Mozilla creating new APIs to make my Zotero extension possible, and as to “seeking feedback”, my repeated offers to volunteer time to build an signing API go unanswered. I am a sole developer doing what I can to help my users — these two bombshells in such a short period make me despair on how I can proceed with Mozilla as a platform.

          1. Curtis Kwong wrote on

            By that time it will be when e10s arrive…

        2. Josh wrote on

          I don’t understand how taking away customization ability would be good for Firefox or users.

          Like I mentioned, if every Firefox extension is just a shadow of the Chrome version, why would people use Firefox? They might as well just use Chrome. I don’t know for sure that this would be the outcome, but it seems like a strong possibility.

          Here’s a comment from your link that basically says the same thing:

          I applaud Mozilla for trying to improve their browser speed (I personally feel as though they don’t get enough credit for the improvements already made). But trying to make addons work “cross browser” is possibly the dumbest idea I could ever imagine. By definition it means that firefox addons can’t access features that aren’t available in other browsers addons, which (also be definition) means they can’t be better than their counterparts from other browsers. Do you have any idea how many of your current consumers are only with you because the addons are better. Many of us have desperately hoped that another addon from another browser would provide similar functionality so that we could leave firefox, but kept coming back to firefox because of the addons. You’re trying to compete with chrome by making a chrome copy??? Your current consumers will leave in disgust and why on earth would anyone leave chrome to adopt an exact replica. If our choices are chrome and chrome-copy then it’s a sad day for all of us. For your own survival, please make sure that before you complete this move. The web extensions API is done in such a way that vimperator/pentadactyl and similar addons remain (in look and feel not in code) completely as they are now (100%). You will never bring back chrome users by being chrome and you will lose your current user base.

          I’m still confused about why this would be a good idea. If it reduces customization ability to the level of Chrome, it sounds like it’s removing the reason that a large part of the most enthusiastic Firefox supporters use Firefox.

  36. Willbur wrote on

    Bad choice, Kemosabe.

  37. Stephan Sokolow wrote on

    And Firefox’s death of a thousand cuts continues. I’ll continue to use it for now, because it’s still more free and configurable than Chrome, but it’s getting harder and harder to force it back to the UI and feature set I prefer.

    (I was already planning to switch all the less technical users under my care over to Aurora channel so I could disable extension signing to grant access to extensions I don’t want to publish… either that or, if the CCK supports it, start maintaining my own builds for the less technical which recognize a second signing key.)

    I’ll probably start hedging my bets by investigating other APIs so that, if a straw arrives that breaks the camel’s back, I can be confident in my ability to write my own browser based on WebKit, Blink, or “anything that exposes a CEF-compatible API” in the time between my switching away from Aurora and the loss of an acceptable version on the ESR train. (Though, if unforeseen delays do occur, I’m not above turning off updates on ESR to buy myself time.)

  38. RM wrote on

    Well, that about does it for me. I’m not an add-on builder, I’m just a longtime user. The “signed add-on” crap made me jump through hoops to disable it so my add-ons could still work, and now this move to WebExtensions so Firefox can be more like Chrome and Opera completely ends it with me. Why should I use a Chrome wannabe when I can use Chrome and not have to worry and spend time jumping through hoops every other week to make my setup and addons to work.

    It absolutely amazes me when a successful company trashes all of their clients – without ever soliciting their input – and tries to remake itself into a poor copy of another company’s product. It NEVER works. Mozilla is going down some screwy rabbit hole and will soon be less and less important in the browser world.

    Off to Chrome…

  39. maurer wrote on

    This change (making it impossible to use xul or the coarse grained permission model, even for users who explicitly want that) looks like it will kill Pentadactyl.

    My biggest disappointment in chromium (indeed the primary reason that I didn’t switch to chromium after some of the recent security scares with pdf.js) is that its extension model does not allow for these sort of full-conversion mods. Chromium has three extensions trying to do the same thing as Pentadactyl, but they all fail to do so, in large part due to the restrictive permissions model.

    I agree that it’s nice to be able to install some extensions with a restricted set of permissions; it makes it easier and safer to try new extensions. However, restricting user choice by preventing users from being able to install XUL-based extensions will remove one of the few remaining feature advantages Firefox has over Chromium.

    1. Josh wrote on

      It’s amazing to see Pentadactyl mentioned here several times. That’s the killer feature for Firefox and Mozilla should officially sponsor its development.

      I can’t stand Chrome or the Pentadactyl-like extensions it has. The privacy extensions on Chrome appear to be lacking as well.

  40. Stink Terios wrote on

    This is a disgrace. I don’t want signed add-ons, I want to be able to add whichever add-on I want. Every browser other than FF is worthless right now, I don’t want Firefox to also be worthless.

  41. Max wrote on

    Sorry if I missed this but when will the WebExtensions API land on the stable channel? I just tested one of my Chrome extensions and it works reasonable well. Do I have to wait a year or can I publish the extension as soon as Firefox 42 reaches the stable channel?

  42. Slam Speech wrote on

    Instead of doing away with XUL/XPCOM, create this new API and make it really open, so MOST developers won’t have to use the legacy method. HOWEVER, if they need the extra functionality that XUL/XPCOM provides. It might be more difficult to keep the extension up to date with changes in the Firefox architecture, HOWEVER, it is managable and it is better than not having that extension at all.

    I have no doubt that the most popular extensions will be supported. NoScripts and TabMixPlus, but what about lesser known extensions like Tile Tabs?

  43. mrpopo wrote on

    How can this be true? I am reading the comments and all I see is add-on developers announcing they are quitting firefox. Multi-process? This is the main reason I don’t use Chrome. I beg you, please change your mind.

  44. Anonymous wrote on

    BLOG (from the palemoon forums): Mozilla to deprecate… itself, really.

    “So, a rather cryptic topic title, but I’m not sure how else to state what seems to be clear plans of Mozilla to deprecate just about everything that makes Mozilla and Gecko code what it is. I’ve listened with increasing amazement to some things that have been relayed to me over the past couple of weeks, to the point where I think people should be aware of what’s happening and what’s going to happen. We may see the end of extensions to Firefox sooner than anticipated. We may also see the last bastion of customizability gone for good on a shorter term rather than a longer term.

    Deprecation of binary XPCOM components in extensions

    Mozilla is working on removing support for binary XPCOM components from the Mozilla code base (this will land in Firefox 40, as far as I know, just 5-6 weeks from now — see bug #1159737). Meaning that any add-ons that use binary components will stop working and will have to be rewritten in JavaScript or die. Of course JS is going to be far from as performant as binary components — and that is usually the main reason why binary components have been included in the first place.

    Benjamin Smedberg wrote:It is time to stop supporting binary XPCOM components in extensions. These represent significant compatibility and stability risk to Firefox users. Ideally we’d stop supporting them altogether, but they are still used by the application in a few important cases.

    This may bite extension developers because so far it’s only been made known in the pre-release channels that not everyone will follow.

    Plans for Servo/Rust

    Servo/Rust is going to be a development project for Firefox that looks like it will be replacing the gecko graphics engine — bits and pieces at a time. Mozilla has, apparently, dedicated budget for this kind of work (see bug #1175663). See also the main repository for Servo, which looks to be an effort at completely replacing Gecko once done.

    Deprecation of XUL and XBL

    More recently, I got information about Mozilla planning to deprecate XUL and XBL from the browser back-end as well, on the shorter term (before moving to Servo). If this happens, all but add-on SDK extensions will stop working, and a good number of SDK extensions may also no longer function if they use XBL. The following was relayed* which is… very disturbing news for the way Firefox is currently running: XUL is the language/framework used to build the interface. It is an easy to learn, extensible markup language that allows you to easily build interface modules and dialog boxes (if you’ve actually looked at Pale Moon Commander’s code, you can see how simple it is to build something like that with XUL):

    We intend to move Firefox away from XUL and XBL, but the discussion of how
    to do that is in the early stages. There are a ton of unanswered
    questions: what technologies/best practices for web development should we
    adopt in its place? How does this affect add-on developers? Is there
    space for a native-code main-window on desktop like we have on Android?
    How much time should we spend on this vs. other quality issues?

    So, without XPCOM binary components, and without XUL&XBL, there’s no extensibility left in the browser — you can’t change a native-code main window on-the-fly that easily as is possible with XUL, since it is basically built up using a markup language that can be manipulated.

    And without the Gecko web browser engine, later on, what is left of the original concept of Firefox?”

    1. lol wrote on

      I wasn’t planning to comment because it shamed me to think of having my words pasted next to all you non-developers who don’t know anything about add-ons besides that you use certain ones but just want to be Angry On The Internet because “LOL CHROME CLONE” is a such an easy meme to repeat.

      But I had to laugh and point out that in your pasted screed, the author states XUL “is an easy to learn, extensible markup language that allows you to easily build interface modules and dialog boxes.” The implication here is that with Firefox moving away from XUL, learning the markup language will be a scary and insurmountable challenge for developers. Yeah, man, that markup Firefox will go toward internally sure is murky and terrifying… what was it called again? Some kind of sinister acronym… HTML, something like that?!

    2. Noitidart wrote on

      “Mozilla is working on removing support for binary XPCOM components from the Mozilla code base (this will land in Firefox 40, as far as I know, just 5-6 weeks from now — see bug #1159737). Meaning that any add-ons that use binary components will stop working and will have to be rewritten in JavaScript or die. Of course JS is going to be far from as performant as binary components — and that is usually the main reason why binary components have been included in the first place.”

      I like this binary deprecation move. It allowed js-ctypes to come in. Which I did, I used to use LightShot but made a non-binary/npapi version using js-ctypes. Lightshot was very proprietary, using js-ctypes it was an open source mentaility. So my uploads don’t go to my server, it goes to what the user wants (ie: twitter, imgur, etc). In light shot, the guy had the NPAPI mentality, so his uploads would upload to imgur and then he would put that on his site ( or something) and then instead of giving us the imgur url he gave us that url which was very annoying haha.

  45. Simon wrote on

    Is there a timeline for when we will actually know which APIs will be available through WebExtensions and which will not? We need to decide whether we should “go native” and ship a small Firefox extension to communicate with our native app, or whether we should start building on WebExtensions, with the promise that it will support the APIs we need in the future. (FWIW, js-ctypes is high on our wishlist.)

    1. Noitidart wrote on

      Yesss js-ctypes is very high! Because talking with native apps is not a solution, much of the code needs to run on the same thread as firefox, maybe not the main thread, but the same process, this is true for many of the native api’s for Windows, OSX, Linux/X11, JNI etc. and js-ctypes allows us to do this. Js-ctypes has a small issue in that it can’t set up a callback from another thread, to happen on the main thread, but once that’s fixed, then we’re set.

      Do you have some js-ctypes work? I’m real interested, I have bunch on my github ( ), please share with me yours I’m eager to see. 🙂

  46. Dave wrote on

    “Individuals must have the ability to shape the Internet and their own experiences on the Internet.”

    And many individuals, including myself, do just that — using add-ons that will no longer be possible under this new regime. On Mozilla’s farm, it seems some internet experiences are more equal than others.

  47. Laci wrote on

    Thanks for destroying Firefox more and more with every update, I and many more will switch to an alternative browser if you remove compatibility with old add-ons. Anyway, enjoy your chrome clone, kuk :^)

  48. Marnes wrote on

    Well, that’s it. Thank you Mozilla, you’ve pushed me to the point where I just don’t want to put up with you anymore. The addons I developed with so much love (mostly because I wanted their functionality myself, but I’ve tried to take good care of users too) are going into the trash now and I’ll gladly be moving to chrome, which you’re so desperately imitating you couldn’t stop your downward momentum and went right past its level of badness. I’m sure I speak for many addon devs when I say I just don’t have the patience for this sort of crap anymore and I’m not gonna rewrite all of them to use some new api yet again after spending so much time learning the last platform. Good riddance and I hope Firefox dies a nice death, surrounded by the gutter-level users you cater to now.

    1. lol wrote on

      “Thanks Mozilla, you’ve ruined Firefox and made it just like Chrome. I’ve had enough of you, so I’m switching to Chrome.”

    2. Noitidart wrote on

      Duuuude, I don’t understand. You are upset Firefox is getting the Chrome Extensions API so you are going to leave Firefox and go to Chrome? Quick hint, when you go to Chrome, you will encounter the Chrome Extensions API again. Not only that, you’ll encounter Google taking all your data from you and making tons of money off of you, without giving you a cent. And google staunchly does not listen to user feedback. Here at Mozilla they posted this for the reason to get feedback from people like you.

      1. Marnes wrote on

        Except that
        1) I won’t be developing for Chrome because those addons cannot be made as powerful
        2) mozilla never listens to feedback either. They always say “oh yeah we’re gonna get feedback from people” and such but I’ve never once seen such a thing happen. They just make something up, post a little bug on bugzilla, have a discussion with the 5 of them, disregard and ignore everyone else, and then go ahead and pat themselves on the shoulder for doing a great job. Hell, I don’t even have a clue where I’m supposed to hear about details of changes, I’ve often come back to the docs of the jetpack API and seen things that had changed or been expanded with no mention of those changes anywhere easy to find. Mozilla saying they care about feedback and such is like microsoft saying they love linux: it’s just marketing and face-saving.

      2. Marnes wrote on

        Also, some of the posts I’ve been reading about this sound like they want us to tell them in detail which APIs we need and how they should work, but how can we possibly help them with that without learning everything about how that API has to map to the lower systems regarding threading and such? It’s like they’re asking us to help them engineer it, which is completely out of scope for addon devs.

        The simple answer to “how should the new API work” is that, if we for example use (in pseudo code)
        var downloadIntegration = import(“downloadIntegration.jsm”);
        then the new API should look something like
        var downloadIntegration = webExtensions.downloadIntegration;
        Basically, the actual code that does the work, the objects you work with, the method calls and events, etc should all stay the same. Just the way you import the code should change.

  49. Clive Manthorp wrote on

    Mozilla Corp. has come full circle. From empowering users, defending individual freedom and openness to this: WALLED GARDENS.

    From now on every add-on is signed and the end user will not have any say. It’s their way or the highway.

    Just like the MODEL WALLED GARDEN: iOS!

    Expect censorship, discrimination, and objection to all kinds of add-ons based on some obscure legal excuses.

    In Apple’s walled garden you can’t have ac-3 (despite the fact that is perfectly legal), downloading from youtube (despite the fact that’s perfectly legal) and no torrenting (despite the fact that is perfectly legal).

    Between most users and developers abandoning ship, and the imposition of these restrictive policies that harm their own users, Mozilla Foundation is committing slow pace suicide.

    They betrayed their own principles, now they betray their own users.

    We cannot underestimate how blindsided and disorientated Mozilla was with the introduction of Google Chrome. Every one of their decisions since has been completely misguided, mostly imitating, ripping off, Google’s product.

    The interface change, an overreaction, that took years to come to something useful, and that was a horrible frankenstein abomination.

    The decision to create a mobile operating system, with a pointless conclusion.

    Partnering with every despicable company in the world: Facebook, Microsoft, Cisco, etc…

    Adoption of things that they swear would never do: DRM and proprietary codecs, among others things. See the recent Pocket debacle!

    Creating and then abandoning useful things, like the improved bookmarking system, the identity system, leaving them half-baked or dead. While concentrating their resources in pointless things like Hello and FirefoxOS.

    Mozilla Corp./Foundation reminds me of Netscape/AOL before they open up the code for what is now Mozilla Firefox. Searching the taillights of the more popular competitor, not knowing how to compete, reactionary, desperate, panicking, hysterical.

    It will have the same conclusion, except this time the Phoenix will rise from the ashes. We live in a world of WALLED GARDENS where they can’t even compete.

    As we saw recently with their hysterical overreaction to an awful interface design, they still think their biggest competitor is Microsoft!

    1. anny wrote on

      Strange. Other people in this thread say firefox’s time wasted fighting against DRM and proprietary codecs is the reason they switched to Chrome.

  50. Mike Harris wrote on

    You say you are soliciting feedback. In all honesty, I doubt that, because the responses thus far from the community have been pretty clear, yet you seem to be proceeding along your course anyway.

    Nonetheless, my feedback is this: I can say without a doubt and without hyperbole or melodrama intended that you are killing your own product.

    If I wanted Chrome, I would download Chrome. I don’t like Chrome. I like setting up MY browser with the functionality I want it.

    You folks need to face up and stop trying to change your identity. You are NOT the browser for the safe mainstream user who needs a safe, easy, walled-garden browser. That may be what you covet, but that spot has been tightly secured already by Chrome, IE, and other users.

    Your successful identity until recently has been the extremely configurable, multipurpose browser for the power user with amazing extendability.

    You as a corporation are doing absolutely everything you can to completely murder that identity, obliterating it from the face of the Earth.

    You are making decision after decision after decision based on the concepts of simplification and greater safety. By doing so, you’re killing Firefox in the bizarre hope of making it indistinguishable from any other browser, so that somehow mainstream people will for some reason mistakenly choose Firefox instead of IE or Chrome.

    Stop it. Stop it. For the love of God, stop it.

    Do NOT make a decision that every browser addon out there needs your specific stamp of safety. You are not the FDA.

    Do NOT completely obliterate the work of every single addon author within the addon ecosystem for over a decade based on a poor decision as to where to take the Firefox browser from this point onward.

    You ask my reaction? You are the captain of the Titanic, blithely deciding that the S.S. Firefox will perform better if steered into some chillier waters.

    1. Noitidart wrote on

      “yet you seem to be proceeding along your course anyway.”

      To be fair man, they just posted this blog post up less then 24 hours ago 😛
      I think people are still in bed, they haven’t gone anywhere hahaha

      1. Mike Harris wrote on

        Addon signing has been announced for a while. This is not the first time it’s been announced and not the first time people expressed their severe dislike of the concept.

More comments:1 2 3 5