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:

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 addons.mozilla.org (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:

Start to consider how existing extensions will make use of the WebExtensions API.

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 http://arewee10syet.com. 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.

Signing

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 addons.mozilla.org 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.

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.

471 responses

I attempt not to resist genuinely needed change. I heard some users complain about the Australis look that’s been out for over a year, but I like it very well. Some drive to change things for the better is healthy. Nevertheless, the current thrust has me seriously concerned.

Security and signing are a legitimate concern, and I have no problem with requiring review. I’m somewhat skeptical, though, of making it impossible for users not running a “developer edition” to opt out, and accept less-reviewed addons. Not trusting users to make informed “opt-in” decisions is a bit insulting. It seems that this arrangement is kind of pushing convenience to the edge, but there’s some good intention in it, and serious extension developers can work within this framework. In short, I can take this one well in stride.

The biggie is any rework of the extension APIs that will eliminate “deep” customization and functionality. This has been one of the best attractions to Firefox. On one hand, a requirement to substitute certain APIs, one-for-one, is inconvenient, but is tolerable if there is a good reason for it, other than “making Firefox work just like all other browsers” – an enormous mistake. But eliminating the low-level XUL-overlay and javascript capabilities will make some of the very best extensions impossible. This path is so suicidal, that I feel and hope that either it will be reversed, or that a well-supported path for the browser will be maintained indefinitely that supports XUL and intimate, low-level customization.

This is a big problem for govt contractors. We cannot legally release our addons to a third party, and Mozilla isn’t on our list of approved hosts (unlike Google).

Now we’ve got a team of FF developers that we can’t use, and no openings to transfer them elsewhere, so we’ll be sending out WARNs next week, and our FF team will be reduced to security updates, and eventually phased out.

Avoiding top-down control is why many of us became FF developers in the first place.

Yes Larry, I totally agree that the implementation of this new API will take away many low-level customizations. I’m sorry to say but a lot of my favorite extensions will be victims of Mozilla’s proposed changes. The feature rich Firefox that we have used and loved all these years is now on the endangered species list. If this ‘fox lives on it will, no doubt, be a castrated version of a once capable animal. It’s the dawn of a new day, sadly one filled with dark skies and storm clouds.

I have been a fan of Firefox since its early days. I have tried to remain loyal and encouraged other people to use it.

But almost all design/security decisions in the last years have had a negative impact on me and my users, leading to outages, problems and a lot of time wasted.

In all likeliness, one or the other tech giant has sponsored moles inside the Mozilla dev team. I cannot explain the complete lack of insight into what users want/need any other way. Or, for that matter, why half-baked commercial services (Pocket, Hello) weasel their way into the core Firefox code.

I will stop using Firefox in my projects and move to support one of the forks if this continues, moving my user base also. This is not a threat, simply a strategic choice to stop shooting myself in the foot by supporting a project gone wrong in the hands of some technocratic illusionists.

Sad news for add-ons and Loyal Firefox users , If we wanted chrome we’d of downloaded chrome Australis is pure garbage and a chrome clone I’ll be moving to Palemoon once this change happens , I’m already there 50% of the time as it is .. what Mozilla is lacking is creativity it’s mission seems to have been bought out and cheapened by a lazy team , who probably use chrome when not at work ..

I realize the futility of trying to argue with a cooperation but I have to say that for a great part of our work, we depend on firefox addons. Now you suddenly say that you are changing these addons to a kind of a chrome version. All I know is that unless we can use tabplus we cant really do our work.
It’s like you are trying to drive your userbase away. Is this some kind of google takeover ?
Are you not interested in your users wishes ?
We will have to get an older version of firefox and just keep using that instead. It’s going to be a mess.

A long time ago, I had the opinion that IE was the “standard” in browsers for Windows. I would chuckle at users of Firefox who would post “problems” they had with websites and webapps. I thought that IE was compatible with everything and why didn’t Firefox just do things the way the IE did them. Or, a more reasonable question in my mind, why didn’t everyone just use IE? Then as time went by, IE and its interface and its compatibility went downhill. I reacted as many did and reluctantly started researching other browsers and the reasons I should consider switching. That’s when I discovered two major concepts that affected my view of browsers and other software: “open systems” and “standards”.

“Standards” for communications protocols and things like HTTP were just that: standards. I had already had an epiphany when it came to printer standards and I would tell my friends who were looking for a printer, “HP Printers are not HP Compatible”. They would be shocked and then I would tell them, “They *ARE* HP”. I didn’t know much about all the “standards” and the dozens of funny ways that they were “named” but I did know that if an HP printer didn’t do what a program told it to do, they the problem – without a doubt – was at fault, not the HP printer.

I discovered that with “standards”, there was a set manner in which things were to work. Therefore, there was a particular way programs, like IE, were to function within that set manner. Well, IE was falling down on the job by not working within the “set manner” and, instead, Microsoft had started doing things their way. I imagine Microsoft thought then (and now, still) that they were so big and so pervasive that they could control such things as standards and drag the whole of the software development community along with them, down their path of “non-user-preference-driven” growth.

While continuing my research into a new browser, I discovered “open systems” and was dumbfounded at the idea that anyone and everyone could actually look at and (legally) modify any program that was based upon open systems architecture. Wow! And Mozilla’s whole business model was based upon using open systems and they had developed Firefox. Even more enticing – and there was a development community that was sharing in the work of continually moving forward with the design of Firefox and shaping it to the requests of its user community.

Fast-forward a few years. Firefox has gone to shit. Mozilla has some sort of perverted agenda to develop Firefox into something that nobody wants – the whole time claiming to be listening to users input. One thing that I’ve noticed… They appear to want Firefox “desktop” to be the same as “mobile” Firefox – abandoning all the vast resources of a real computer with a real display to develop in the crippled environment of a phone with the screen size of your palm. P.S. Firefox mobile is shit too.

For me, the most recent stabbing in the back is the sudden and unwarned disabling and blocking of SSL Version 3. This has resulted in the inability for all users to access websites that use SSL3 – which is still the most common secure connection method – and there is no work-around via normal security settings. I have heard of entire companies who have converted over to IE just to get around this problem. A colossal waste of time and resources imposed upon them by a company who is supposed to be the champion of the user both small and large. Of course that begs the question, why doesn’t Microsoft feel this is a big enough problem to cripple all their users over?

Okay, I can understand Mozilla’s need for security and I’m sure someone is looking out for liability on their part but they have chosen to make it impossible, through normal “options” to access websites that are vital for many users to get to on a daily basis. In my mind, this would be one of the high-ranking definitions of being shit.

Although it hasn’t crippled anyone yet, they now propose to add to their poor decision to push towards “commonality” by developing under the “mobile” platform model, they plan to push towards commonality with Chrome and Opera by COMPLETELY changing the platform upon which all add-ons are developed. I have to ask, why in the world would anyone at Mozilla want to make Firefox “more like” Chrome or Opera? Does Ford make their cars “more compatible” with GM cars so parts manufacturing companies can make just one engine for both companies? Or just one hood or just one dashboard. If they did then why would there continue to be a need for two such car companies. Oh, wait! Have I tripped across something? In this car-manufacturing nightmare that I just imagined, wouldn’t it be smart for one company to buy the other? Of course it would be – it’s the American way – and it would be a merger of two companies that would be more compatible than any other merging companies in the history of business. So where would that leave Firefox, Chrome and Opera? It sure looks to me like Firefox is grooming itself to be picked off by Google and turned into – let’s see, what would be a good name – “SilverFox”? Does anyone like that name. Well, a rose by any other name would then be just as lame – as Chrome.

Warning Mozilla… You are looking to turn shit into what would be the next logical step: dust.

It is going to be very difficult for us developers who augment the application (both Firefox and Thunderbird) UI using overlays and global objects to recreate the additional functionality we currently offer our users if the current trend to restricting our tool set continues. XUL and overlays are very powerful technologies, in my eyes they are the biggest advantage over chromium, and now it seems that those of us who embraced these technologies the most are penalized over those who went with the Chrome model.

Another concern is that as a desktop developer who works with a lot of the internal structures in order to create a more powerful tool for handling the users data may soon be in a position were we cannot give our users the added functionality they are used to because the access to global objects is suddenly taken away. The only option in this case would be to try and bring the users to forked / outdated versions of the application (e.g. Postbox, SeaMonkey) in order to increase the Extensions lifetime.

I would acknowledge that it is sometimes challenging to follow the changes in the code base, but this is nothing compared with taking away the most useful technologies for improving the desktop experience.

Us addon devs we are really dedicated. I would say more so then Moz employees. As soon as working hours are over, most of your employees sing off of IRC. Us addon devs are online 24/7 helping out users getting into addon dev, maintaining our addons etc. Please don’t pull out our old capabilities and make our addons be able to be ported to non-Firefox browsers. We are devoted to Firefox and want to keep our stuff Firefox only, we don’t want some newbie devs from GChrome coming in and stealing our work and putting up on GChrome or other browsers.

Please just add WebExtAPI so Firefox can steal all the addons from other browsers and bring it to Fx, but keep the old way (servo-ized or something, html is ok instead of xul) so that Firefox addons can never end up on other browsers (as it is now).

WebExtensions API doesn’t include an HTML printing API. We are using some extensions for printing HTML pages and it may not work with new model. Here is the suggestion for printing API that can be included in WebExtensions API.https://gist.github.com/anonymous/44dea23c9c0888db185b

I think a clear message needs to go out on what the future holds for the SDK. Will this also face future deprecation or can we as developers invest time in using it to replace what we currently have instead of waiting for WebExtensions (particularly if we don’t give a shite about Chrome)?

So, I use moz/ff from 0.x versions, for because customizable functionality and because devs work on web standards support. For now, devs made madness in every version changin APIs, work on integration buggy nonsenses and totally ignore users. Theirs priority si whom like or dislike gays.

Mozilla continues -gave up- its work on web standards: finally we have a standard for the chrowser. It’s all one big family! Chrome, Chropera, Chrofox and the just born baby Chrovaldi!! Which one will you choose?

By using a chrowser, you agree that Google Inc. has the only right to define web standards.

I know my comment isn’t going to change anything – I just wanted to say how much sadness I’m feeling right now. It’s probably not good to be so emotionally attached to software, but Firefox has been part of my life for a very long time and primary reason for that was it’s openess. I sincerely hope in some trustworthy fork.

My addons are heavily dependent on the addon sdk. I have quite a few and they are firefox only by choice. I don’t have the time nor the desire to rewrite them all from the ground up to make use of the webextensions so I hope you can fulfill this request.

Since the functionality is already available in require (“chrome”), mentioned above. It should not take too much effort on behalf of the mozilla devs to write simple access limited APIs around them for the sdk.

Well, I love the add-ons in Firefox. And this looks like a large number of them will simply vanish as it will require a COMPLETE rewrite for a number of them that the authors of said add-ons may not be able to take care of easily. I have read somewhere that like the Down Them All add-on may have to simply fold is disturbing.
It appears that Mozilla is trying to make a lot of add-ons vanish. And as I read somewhere, Firefox without add-ons is just a plain disgusting vanilla browser, no matter what is done elsewhere with the product.
As such I am also seeing a lot of comments leaning towards finding alternatives since this will also well to put it mildly piss off a lot of the user base.
I can understand security and wanting to prevent breakage, but such draconian measures can only end badly.
I am also now going to have to find an alternate “just in case” browser. Just to be safe, if Mozilla screws the pooch in this.

The only reason, only reason I use Firefox, can’t speak for others, is the number of fantastic extensions and add-ons available for Firefox. Stuff like Downthemall, Flashgot, Shareaholic, Videodownloadhelper, No Script, Flashblock, etc. If they don’t work with your fancy new stuff, then Firefox goes out of the window immediately. Don’t try to be a Chrome clone, we’ll just use Chrome if we wanted something like that. You guys have down awesome stuff, the arguments in the blog don’t really justify huge changes. But really, somehow I get the feeling you guys won’t listen to users and die a slow death in the future.

im just a user but if the addons wont work, or work in a worse way than they do now, and i end up not being able to browse porn sites without getting malware im outta here so fast i might overtake the roadrunner

i want to block adds, and scripts and stuff i dont even know what it does, i want to be able to fish inside noscript for that elusive video and block everything else, because when im lookking at porn i do it one girl at a time, i dont cheat on my porn girls, i do it one at a time, thats respect and class right there, i cant be having distractions and other girls poping up left and right, nah uh. FULL FOCUS
Also knowing im breaking websites and probably they are having a harder time to follow me around and track me and they are starving because their adds dont work on me makes me feel awesome.

From a short, partial and quick reading of this, I have this question:

Is XPI and CTypes gonna be deprecated as well ?

Apart from passing pointers from the browser to your native DLL with CTypes, I think that the rest is working very similarly with Chrome (with messaging for content-to-browser-script-communication and all).

Can you please tell me what you are going to do with this (XPI/CTypes) technology?
I have been working on an add-on lately and gathering the documentation pieces from the most unexpected places on the Internet and I hate all this work to go to waste…

—

Apart form that, reading about you using a totally new architecture for your browser and using a totally new language (Rust) makes me want to wish you good luck. 🙂 I don’t know how wide-spread Rust is, but if it is to help you eliminate bugs and perhaps improve performance, I guess it is a good thing.

Also, I think using the same addons as Chrome is not a bad move (although there are some points in Chrome’s addons that I don’t like).

—

P.S.: If it could be possible to make your new browser lazy-load tabs better, it would be nice. Your current one does this, but I tend to have around 150+ tabs open permanently on my machine and it seems pretty CPU intensive.

—

Other than that, I am excited and waiting for your “Let’s Encrypt” service to come on-line. Very good initiative indeed. 🙂

I would wish there was something similar for signing executables for free too (since unsigned executables or executables signed with stolen private keys containing spyware/viruses is another source of privacy loss), but I guess this is not in your intent/capacity/interest to tackle.

If Mozilla goes through with the announced changes I will no longer use or support Firefox. I have used Firefox as my primary browser since the fall of Netscape however I will (if necessary) COMPLETELY stop using Firefox.

Why somebody named dead-squid is in charge of making my Firefox dead-in-the-water? Who are these people in Mozilla who seemingly adopt a goal of destroying the best browser? Does the community have a voice? People who want speed and security use Chrome, period. If firefox is not a geek browser then it’s nothing. How much harm are those people allowed to do to firefox community before realizing this?

I say sign up and really help shape the addons future. We can really make it clear to the team how we used addons and how we want to maintain that uniqueness, where our firefox only addons cant be ported to other browsers with copy paste. Sure people can rewrite from scratch, but as long as our unique addons that make firefox, firefox, cannot be renamed and used in other browsers. Of course we should make it so that addons of other browsers work right off the bat with Firefox 🙂 I applied and I hope to do that. you should apply too 🙂

The web rendering engine is fairly tangential to how add-ons work. Maybe you mean that Mozilla plans to become a Chromium fork or something like that, but that’s also very wrong. For Mozilla to fulfill its mission, it’s pretty much a necessity for there to be competing web browsers and competing web rendering engines. Guaranteeing there’s a free and open (and independent!) alternative is core to what Mozilla is about. So, no, I don’t think we’ll drop Gecko anytime soon. Maybe Servo will include a whole new engine, but that’s still far away.

“06 – The effectiveness of the Internet as a public resource depends upon interoperability (protocols, data formats, content), innovation and decentralized participation worldwide.”
“07 – Free and open source software promotes the development of the Internet as a public resource.”

What about that Pocket integration? Why not propose a standard/rfc for a service like that? Oh, yeah, the market-share.
What about those social share buttons? They provide services to something closed, right? Why not propose a standard for content sharing that those social networks can adopt, not the opposite? Oh. Market share again.

It seems no one here forgot about Mozilla’s mission. Maybe Mozilla does.

Also, supposing Mozilla is dropping Gecko for WebKit is not an absurd: WebKit is also open.

I think the point everyone seems angry is: people don’t believe in Mozilla’s mission anymore, or at least they don’t believe Mozilla is able to fulfill its own mission (even being a noble mission as it is).

Cumbersome three clicks for unsigned https, forced signed extensions breaking my customized addons, releasing often and breaking the user interface with each release, third party closed software integration, killing the addons completely, what are you thinking? You (Mozilla) have to understand that we (users) want the browser and the interface just to work the way we arranged it, with extensions which we installed, we definitely don’t have the time to fiddle for hours with the browser for every new release to restore the functionality, nor we want to compile the browser ourselves. Like 99% of the users, I am approaching the breaking point. I am going to continue to use Firefox while it works the way that it does now, but I am definitely looking the PaleMoon or Chrome way. If you have too much spare time, instead of alienating the userbase you should do something constructive, such as:
1) Dump WebExtensions completely. Don’t even think of compatibility, or else you are going to be absorbed by Chrome. Keep backwards compatibility of extensions API.
2) Option to override signed extensions. Bring back the preferences in the preferences window
3) Improve rendering and javascript engine. Eliminate memory leaks
4) Keep the multithreading model, share as much memory as possible and keep the browser with small footprint
5) If you need to integrate something, what about AddBlock?
Even if you are serious to keep Gecko, if you continue the way you started, I can bet my money that within two years you are going to be under 1% of market share. So there will be no revenue for development, and you are going to dump Gecko anyway.

What about XULRunner? And the applications built on top of it will still be supported ? With WebExtensions building desktop application will be possible with os-specific look-n-feel ? I think at the end only one company will rule, i.e., “Google”. Now Mozilla is folding its hand. f**k

There are 439 comments now, and I’m not reading all of them. And maybe no one else will be reading mine.

I have used firefox all these years because it loaded pages completely and fast, plus it had no extra luggage. My main browser has been Nightly since I had a 64 bit system. I have a few addons but the main add-on is DownThemAll. Firefox got so crippled that I use it for general browsing but I have to use Chrome for my main stuff since that allows me to remove the Flash install and updates that constantly have to do manually (I don’t want it to update automatically).

I see firefox is going to be one more browser, until it dies. I don’t care, there are more. But you are going to take away Thunderbird and I have no replacement for it. (In fact you’ve slowed down its development time ago).

Super sad.

I can’t say how many times people decides to kill their own, while the community tries to support them (is not that the market or competitors killed them) Amiga, OS/2, Netscape, Qt, Firefox just to mention a few.

Just let both extensions methods live!
Stop developing the old system, but please let it live!
A lot of addons aren’t actively developed and they won’t migrate for sure.
Many other addons can’t be migrated (or require a lot of work).
Killing most of current addons will just decimate the userbase.
Why???

The world does not need another generic, plain vanilla browser. There are plenty of them out there. What the world *does* need is power-user’s browser. Up until now, Firefox was such a browser. It serviced the niche population of developers, power users, and bleeding edge innovators. When Firefox becomes an also-ran, someone else will pick up the torch and continue the path that Mozilla initially forged. What a senseless waste.

…and that’s exactly why people are so disappointed with Mozilla’s current direction. From an open, user-centred organisation it’s become an out-of-touch coporate monolith stuck in an echo chamber. Very sad.

Goodbye Firefox. It was a good run but over the past few updates you’ve really buggered things up. Pocket? No I don’t want that. Hello? Get the hell out. Now this crap? Goodbye. This really really sucks. I refuse to use Chrome or Chromium, Midori is a joke, Opera is trash, Edge/IE/Whatevertheyrecallingittoday oh who cares I don’t run Winblows. ARHGHHGG!!! FU MOZZILLLLAAAAAAAAAAAAAAAAAA

I understand the desire out of ease of development to eliminate XUL, but this might just doom Firefox:

From users’ perspective, many of their favorite addons would simply die. Those that don’t die, already have Chrome counterpart. Then why use Firefox at all?
From addon author’s perspective, the only benefit this whole thing brings is easier porting to Chrome. But once I took the pains to port to Chrome, why would I want to use Firefox at all?

Firefox’s slower, its debugger is light years behind Chrome’s, its recent memory management kept having issues, and its becoming more and more a Chrome-wannabe. XUL is the only real advantage and distinction remaining in Firefox, eliminating it to emulate Chrome better, will at best create a Chrome clone that no one would choose over Chrome itself; and at worst, a more likely scenario is that it’d doom Firefox. I know I’m going to move away from Firefox myself, along with all my addons – if I take the pains to rewrite the XUL-dependent ones.

“I understand the desire out of ease of development to eliminate XUL…”

Who says development is supposed to be easy? XUL is complicated, but also very powerful. With powerful tools, one can develop powerful add-ons. I’ve spent a decade developing with XUL and XPCOM and I’m still learning the language and its capabilities. Yes, it’s challenging sometimes but making things easier does not necessarily make them more desirable.

I’m old enough to remember JFK’s speech 53 years ago:

“We choose [to go to the Moon and do other things], not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one we intend to win …”

By dropping XUL and XPCOM, Mozilla is taking the lazy path and makes me wonder what the true reason behind all of this really is. It’s certainly not to make Firefox a better product. I suspect there is some hidden agenda that we’ll never know about.

If XUL is interfering with Firefox development, change whatever is broken in XUL – don’t just drop it.

I don’t mean to sound maudlin, but that speech affected me then, and still does today.

FF used to be great because you didn’t fix what wasn’t broken. Now there are a constant stream of updates that have way more than just security improvements. You keep changing the format (i.e. how it looks & where things are located & removing things that WORKED and people LIKED & USED). You also make it harder to navigate (i.e. having to make more mouse movements/keystrokes to do the same things it took less to do in previous versions).

I am not a techie. I have no clue what goes into maintaining a browser. BUT, IMHO this is overkill. I cannot tell you how much I appreciate the wonderful people who are doing FF users a HUGE service by creating and maintaining FREE extensions that make our lives a whole lot easier. I don’t use that many extensions, but the ones I do use are the only reason I keep using FF. I like the simplicity of the older versions and I’m tired of losing themes, lazarus and now FBPurity is on the chopping block. All because they will now have to rewrite everything or we will lose valuable extensions/add-ons, That is ridiculous!

I suppose now I will also lose the ones that make FF more usable and bring back features that made it EASIER to use FF. :-((

Why not let us decide if we want to continue using at our own risk? You can put a disclaimer w/all the legal mumbojumbo you want so we can’t sue you.

I have always appreciated that FF allows us privacy (cookies) options. Sadly, now that is THE ONLY REASON why I have continued to use FF. Safari doesn’t and chrome is way too invasive. I haven’t used IE in years.

Profit or non-profit – it doesn’t matter. What matters are the MAJOR STAKEHOLDERS and that, you seem to forget, is us the END USERS. Without us, you don’t exist. Not that you seem to care…

The day FF requires add-on signing or drops XPCOM and XUL is the day I uninstall Firefox.

I’ve already put up with a TON OF CRAP from FF regarding Pocket, Hello, advertising, DRM integration, ridiculous UI changes, ridiculous changes to default settings and the outright removal of settings (third party cookies, global disable for javascript, killing old versions of SSL making it IMPOSSIBLE to connect to things such as my networked UPS, etc.).

Firefox is supposed to be open and free for users and developers. Mozilla seems to think everyone needs to use Chrome.

I warned you, I begged and pleaded, but you did not listen. I am writing this from Palemoon, and I have switched mine, my family and friends, and all work related computers as well. When you beg for your user base back, it will be met with the same indifference that you have shown us.

The Moz devs are concerned about the silent majority and not about individual (“power”) users who didn’t even like Australis. But you can disable Australis features you don’t like, so it’s not an issue. The issue IS that forking Firefox is not the solution – with Pale Moon lots of addons are already “wontfix” and the more Firefox progresses the more you’ll be stuck with outdated versions or unmaintained xul addons.

I don’t really like Firefox ever since you went crazy with the version numbers, and a little later merged desktop and mobile UI’s (Australis).

I don’t even trust Firefox anymore, ever since cookies became invisible when using Private Browsing Mode. (Try it, it’s fun. All the cookies are still there in memory somewhere, but you can’t see them and you can’t edit them, and you can’t even delete them. Extensions such as “Cookie Editor” don’t see them either. If you want to be sure they’re gone you need to restart the browser. Well I suppose you could use the “Forget” feature, but how do you know it works when the frigging cookies aren’t shown anyway?)

Despite the above, I’m still a Firefox user, and I’ve been one since version 2.0.-something, although nowadays I only use the ESR version. But soon enough I will just switch to another browser. Do you know why? The extensions! It’s bad enough that extensions sometimes break just because I upgrade the browser, while as a user I get no compensation in terms of functionality or performance. New version number = extension broken, is all I get. But now, the threat is that broken extensions will be left broken for good.

What kind of stupid move is this on your part? Who the hell cares about cross-browser compatibility? The user? Yeah because as a user my primary concern is “hmm, I sure do hope this extension works in all my other browsers as well”. You don’t care either, because it makes no sense to be concerned about addons made for YOUR browser to work in competitors’ browsers. Or you want addons made for other browsers to work in Firefox? WHY?! Or maybe you THINK addon developers care about cross-browser compatibility? Actually I’m unintentionally setting up a strawman. Maybe you’re simply getting paid to destroy Firefox so that Chrome can take over.

Why aren’t you replying to any of the legitimate concerns here from add-on developers? Don’t you care?

You justify WebExtensions by saying, “For some time we’ve heard from add-on developers that our APIs could be better documented and easier to use.”

Well now in this thread, you’re hearing from add-on developers that WebExtensions is a TERRIBLE and SUICIDAL idea. But you’re IGNORING these add-on developers.

This suggests that you were lying in your justification of WebExtensions. It also suggests that you have an agenda, and that you have nothing but contempt and disrespect for Firefox users and add-on developers.

Replying to 500 comments isn’t very practical. Some of the concerns being brought up here are either addressed already in the post or remain to be resolved. The WebExtensions API is being developed now and it’s up to everyone to shape it up for success. There are various feedback channels, namely: uservoice to suggest APIs for WebExtensions, the Add-ons Forum to discuss WebExtension development and also provide feedback (I recommend reading Giorgio’s proposal for low-level access), and the add-ons user-experience newsgroup for broader questions about strategy and how it all fits together. These comments are also being read, and the points being brought up are being noted. However, debating here isn’t very effective and there are many moving parts at present.

So you describing a new Mozilla’s way to success:
1. Take something brilliant, working, non-broken, satisfying millions for years
2. Replace with a piece of cr… stuff that nobody wants
3. Make it “up to everyone to shape it up for success”
…
4. PROFIT (for whom???)
There is a Russian proverb that perfectly describes this: Из гo..на конфетку сделать (Work hard to make a candy out of sh…).
And there is an excellent one about the remedy for problems that Mozilla have chosen: Лучшее средство от больной головы – топор (The axe is an ultimate cure for headache).
Mozilla as a parent of the Firefox sees nothing wrong in a feeling that Russian classic described: Я тебя породил – я тебя и убью! (It’s me who gave you a birth and it’s up to me to kill you or not!)
But the question is: do they really have a moral right to destroy something that not just them but thousands of volunteers donated years of man-hours of hard labor into? I’ve just read that Mozilla itself estimates that 40% of it’s code came from volunteers. I couldn’t even imagine how much of man-hours this is combined with numerous non-profit developers of extensions. And mozilla doesn’t feel any moral obligations towards this contribution? They just say: “we’re just tired of old code – f..ck it, we will start from scratch and make a new browser for our own pleasure”.
Mozilla, rethink this please! Today you’re ditching thousands of developers – tomorrow millions of users will ditch you. Power users are the people who bring you millions of others – not the other way around.

I work at a large software company. I use Firefox exclusively. Someone developed a FF plugin for internal use that made my life so much better. Now we can’t have plugins for internal use because FF wants to review all plugins, to save us from ourselves.

Can’t you at least allow people to install plugins with a giant red flashing sign that says “NOT REVIEWED BY MOZILLA — COULD BE MALWARE! ENTER AT YOUR OWN RISK!”

Microsoft assumes its users are unable to make their own decisions. Are you really walking down that same dark path? I fucking HATE Chrome, but it’s like I’m being forced there against my will

When it comes down to it, it’s addons and customization what make Firefox better then any other browser out there. You could always custom-tailor your FF for your own, personal needs.

By deprecating XUL-based add-ons you’ll basically make FF worthless.
As things sand now, Chrome and new IE are faster and feel more responsive when surfing the web, than fresh installed FF. But people are still using FF and it is only because of Addons.