Mozilla Add-ons Community Blog
Categories: compatibility developers webextensions

The Future of Developing Firefox Add-ons

471 responses

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

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.

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. hosein abedy wrote on

    very good

  2. LimboSlam wrote on

    @Tom: sounds like you know a little bit of coding. Just wondering because I’m too a Pale Moon user that has couple of problems getting some of my add-ons (currently testing out their beta version of PM, v26.0.0pb1of the Goanna engine) to to work with me, so maybe you could help us out with getting certain add-ons to install with us. Please feel free to post on our forums if you have any questions or want to report an issue.

  3. Frank Bennett wrote on

    I am a working academic. Over the past seven years, I have developed a research platform (a reference manager) that serves the needs of academics working in multiple languages. When I began work, no such tool existed, and no other such tool exists today.

    This is not because there is no need: it is because, unlike medicine, or physics, or history, or mathematics, or political science, there is no ready-made channel (such as an academic conference) through which to market a tool for use by “researchers using multiple languages.” By building the tool, I have created that channel, and a community of users now exists. I would like to make two points about this:

    (1) These are people who need to manage their research data across their careers; and
    (2) This kind of innovation, where members of a community help themselves, is aligned with the original vision of the Internet.

    The tool is a complex Firefox add-on, very heavily based on another open-source add-on that is separately maintained by another project. I have run the code through the signing procedure, and it does not look like it’s going to clear – I can’t even reach the submission stage.

    I am seriously concerned that the signing procedure alone will bring my development work to an end, and that would be a very, very bad result, both for me and for the community that I have been trying hard to support.

    1. Jorge Villalobos wrote on

      What do you mean about not reaching the submission stage? If you’re having problems with the site, please email amo-admins AT mozilla DOT org.

    2. Noitidart wrote on

      Oh man I over time have come to rely on addons like your careers do. I totally undrestand and for oursake I hope they don’t deprecate the xpcom, and just change the backend to servo so its same for addon devs.

  4. Not Important wrote on

    It’s over. Firefox is finished.

  5. Firemage wrote on

    I don’t like the idea of FF being any more chromelike, sure modernize but don’t do it by getting rid of what makes FF special.

    I’ve used FF since before 1.0, and i’ve used addons of all types. From classic theme restorer to noscript there are powerful addons i am quick to install when i set up a new machine. If they won’t work any more i’ll have to find a fork where they do.

    But given that there is alot of fire and 2 years before anything big changes i’ll wait and see.

    Don’t kill the power user features, it is one of the things that keeps us coming back.
    If the new system works like the old one just with a newer code base, then people will stick around, if not they’ll find another project that suits them.

    -G

  6. Leon wrote on

    I will just say that if Classic Theme Restorer did not exist, I would have stopped using and recommending Firefox after the Australis transition. The Devtools in Firefox still lag behind in many areas that Firebug 2 was able to provide several years ago. Why can I view cookies in a cookie panel but not mass-delete them and have to resort to Shift+F2 and one-by-one commands?

    The continual gutting of customization options in Firefox is tragic. I know the XUL/XBL/XPCOM removal has been a long time coming, but I was not expecting its replacement to be a completely neutered, pale shade of its former self – I already have Chrome for that.

    /rant

  7. Rickyo wrote on

    Guys you are unintentionally converting the good old Firefox to a new laggy Chrome. Let’s be frank, Firefox does not have the power nor the talent to compete with the Chrome. If you are going on their direction, you will be smashed down. The only thing keeps people using this browser is these small extensions helping them customize it the way they like. That is the only thing. We all know Chrome is much faster, better in security and better in all other aspects except its limitation on customization. I mean core customization, not these powerless extensions it has.

    You have already lost many users. At least go to Firefox channel in Reddit and see how people are not satisfied with Firefox because of its performance issue.

    Let me emphasize one more time: “After these changes the only thing remains is a laggy Chrome.”

  8. Haider Rehman wrote on

    Just make a new browser. Don’t destroy Firefox.

  9. Vess wrote on

    The only reason why I am still using this horribly slow bloatware called Firefox is because it has so many extensions that I need. Sadly, many of them are no longer developed and there is absolutely no hope that they will be updated to suit your new system of whatever.

    Australis was horrendous enough, but fortunately I found an extension that made it half-way bearable. Now this! Well, I guess I won’t be moving past version 41 – at least until the first serious security hole is found in it. Hopefully, a better browser would be developed by then – by somebody else, because you morons have proven that you cannot be trusted to maintain a good browser.

  10. Duane wrote on

    For the longest time it seemed like the only thing that made Firefox different was the wide selection of great addons. Now that we know that anything that made it different will disappear, there will be no reason left to not use Chromium.

    Australis didn’t bother me as much as other people, but now addons developers are saying it too: you guys are killing off Firefox: http://www.downthemall.net/the-likely-end-of-downthemall/

  11. Jim wrote on

    I’m concerned this will kill innovation by limiting add-ons to things that have been done in the past. Why can’t we have two classes of add-ons? One that is restricted to the APIs and can be installed with a click, and another that can access the guts of Firefox and native code and has to be installed like a regular application with root/UAC? And in order to have your add-on in AMO, you would have to migrate it from the continuously deprecated kind to the safer kind as soon as the APIs you need become available.

    1. Noitidart wrote on

      I like this idea.

      The limiting creativity was also something I was worried about. Just if the API doesn’t have a badge profile icon feature for example, then an addon of the WebExtensions type wont be able to do it sounds. Right now there is no such native icon badging feature in any of the APIs but it was made possible via the accesses we have currently.

      I really am worried about limiting creativity, it makes me feel like a non-engineer 🙁

      I strongly support the two type system. I am very understanding of the permissiveness and totally understand the duration of time it takes for addon reviewing and don’t complain. So I will opt for the classic bootstrap addons. I wouldn’t mind if review took longer to ensure I was doing e10s stuff right if they alowed me to keep doing what im doing (minux the xul/xbl i learn to live without it)

      1. Simon wrote on

        >>> Right now there is no such native icon badging feature in any of the APIs but it was made possible via the accesses we have currently.

        There is – https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/ui_button_toggle#Badged_buttons

        1. Noitidart wrote on

          Thanks Simon thats badging for buttons thats cool i was talking about native icons: https://github.com/Noitidart/Profilist/issues/18#issuecomment-46795390

  12. dakoya wrote on

    And with this, Firefox itself is now deprecated. There’s no reason for a user to touch Firefox when they could just use Chromium, which STILL has a better UI than Australis.

  13. faithful user wrote on

    You’d better not reduce the possibilities of addon customization with the new API, you’re fucking crazy to think ff will live after that, just gonna name a few, NoScript, Tab Mix Plus, DownThemAll, kill anyone of this and you’ll see your already 9% market share drop like a rock.

    It will be a fucking sad day if this happens, but if the community switches, they won’t think twice about coming back.

    I feel sorry for you, i always tried to love firefox to the sky, been using it since i remember like 07′, don’t disappoint me.

  14. NoBS wrote on

    Hey there,

    one reason I use FF over chrome is gesture support on linux; in chrome it just does not work. Other reason is vimperator, for which there’s no matching chrome extension. As a end user, I would sum it up that the chrome extensions suck. FF webextension APIs will be close to Chrome’s, so my question is: is it going to suck the same way Chrome’s extensions suck ?

  15. kwerboom wrote on

    I’d be more OK with extension signing if it weren’t constantly invaliding my copies of HTML Validator and ColorZilla. I installed the unsigned versions from the developers’ websites years ago and then installed the signed versions when said developers put these extensions on AMO. Now, since Firefox 41 Beta hit, Firefox keeps saying “Some add-ons have been disabled. The following add-ons have not been verified by Firefox”, so I have to keep reinstalling HTML Validator and ColorZilla.

    Listen, I understand the whole extension signing thing. I used Internet Explorer 6 back in 2002/2003 when ActiveX drive-by installs were happening. Also because of all the “fun” ActiveX caused, I can also understand the move to a cleaner API and tighter standards. That being said, could you please get this right before you shove it out the door as Australis was initially a pain to get use to.

  16. Noitidart wrote on

    Change is good. I’m just hoping that the addons that are possible now will be possible with them.

    I didn’t hear mention of js-ctypes, pleaase don’t remove that, and many cases we need to run the code on a specific thread for it to work (its the nature of the some of the API’s among WinAPI, COM, ObjC, CoreFoundation, CoreGraphics, GTK+, GDK, X11, etc). Will this still be possible? Please yes 🙁

  17. Noitidart wrote on

    Oh and my biggest pride about my favorite addons I made is that it is not possible to made for other browsers 🙁 That’s an edge firefox has, please don’t remove that edge :'(

    1. Riik wrote on

      Hi Noitidart! I love you addons! I wish that I can also keep using them in the future!

      1. Noitidart wrote on

        Hey Riik! Thanks very much!! 🙂 I love my users and you! 🙂

  18. Sylvain wrote on

    Any impact on NPAPI (Flash, Silverlight, …)?

    1. Jorge Villalobos wrote on

      This doesn’t have a direct impact on NPAPI, but you should know that this technology is already in a deprecation path and will disappear, probably in a similar time frame.

  19. Oli wrote on

    This is terrible! I really hope you reconsider before it’s too late… I won’t be able to use Firefox without addons which depend on the old stuff…

  20. Kohei Yoshino wrote on

    Posted the Japanese translation of this article:
    https://dev.mozilla.jp/2015/08/the-future-of-developing-firefox-add-ons/

  21. Ben Bucksch wrote on

    The core advantages of Firefox over other browsers, and the core reasons why Firefox got popular in the first place and users choose it are:
    * Security
    * Privacy
    * Freedom (Open-Source)
    * Extensions

    You’re getting rid of these advantages one by one.
    * Other browser have caught up in security (more or less, depending on browser).
    * You’re gathering more and more data about users
    * Firefox as binary is no longer open-source (in fact, it’s now like Netscape 6), and you’re removing freedom by starting censorship of addons by introducing mandatory signing.
    * And now, finally, you’re removing the powerful extension mechanism that can extend any aspect of the browser, and replacing it with a superficial API like Chrome has.

    Extensions really are the main reason I hear from people around me why they still use Firefox. Now, you get rid of them as well.

    You’re not only shooting yourself in the foot with this, you’re shooting yourself directly in the head. Let me correct that: Not yourself, but us. I helped build this thing that you now actively destroy.

    1. Noitidart wrote on

      I think the main reason of Firefox is not only the extensibility but the trust in downloading anything from addons.mozilla.org

      I know some users on Chrome ( tried to get them to switch to Firefox) and they dont use any add-ons they are very scared to download anything from there.

      So I think Firefox’s pros are:
      * Total trust in downloading anything from AMO (addons.mozilla.org) (very strong user sell)
      * The power of the addons (very strong dev sell – and a good user sell)

    2. Gylgamesh of Uruk wrote on

      I couldn’t agree more!

      We need to mount a strong resistance to this destructive change policy.

      After all, a free browser belongs to the many millions of people that use it every day and donate to it and its add-on developers, and not to the very few individuals that have somehow assumed a leadership position in its development.

  22. Noitidart wrote on

    Also we should remind everyone getting sad (including myself) that this is a blog post to get feedback/feel out from feedback. 🙂

    So even though this isn’t a deployment, it was a hard hitter, and it reminded me of this awesome flowhart regarding “should i deploy on friday night” hahaha:

    https://pbs.twimg.com/media/BkNT8X-IcAAPk07.jpg:large

    1. hello wrote on

      Hi Noitidart! I love your addons! 🙂

    2. Fan wrote on

      Hi Noitidart! I love your addons! 🙂 I hope I can also use them in the future! 🙁

    3. anon wrote on

      I think it’s quite obvious that many people reading this article (they probably only read the headline and one sentence chosen at random) and reporters reporting on it at major sites have gotten the idea that firefox is removing ALL of its addons and replacing them with the ability to download addons from the Chrome web store. This is 100% incorrect but many comments here seem to indicate that is what they’re thinking and I’ve seen a few tweets saying the same.

    4. Noitidart wrote on

      Thanks @hello and @Fan! 😀 I love to build them for the awesome Firefox users! 🙂

  23. Jonah wrote on

    In the new(er) extension development models, how are things like preference dialogs implemented? Several of my existing XUL extensions use preference dialogs to allow users to set up customizations, and I’m not sure what the corresponding machinery looks like in these new models. Are there examples of this kind of thing anywhere? One thing Mozilla has always been terrible at is documentation…

  24. Exalm wrote on

    Thanks. I was able to greatly simplify my yet unreleased extension now:
    https://github.com/Exalm/search-sidebar/commit/7c199df2ed56782bb94197759d02958ba2276b27

  25. Mudrock_ wrote on

    Seriously, stop it.

    Why are you trying so hard to get me to switch to Pale Moon or something else?

    I keep using Firefox because I’m free from this bullshit and I can use whatever addon I need in order to make my experience better. Firefox no longer performs nearly as well as it used to. Google Chrome in my experience has been far quicker, but because Chromium betrayed my trust by sending my data to Google, I have switched back to Firefox. But if this is the route you are going to take, why should I stay on Firefox? You’ve taken a once good and solid release, made it bloated, and now you want to rip the community in half?

    I hope the money you are getting paid for all of this is worth it, because if this is the choice you want to make, I have absolutely no reason to stay on Firefox any more. I can use Pale Moon or another fork that actually DOES care about their Linux community.

  26. Wasi wrote on

    Which of these _Security_ and _Privacy_ extensions will be unable to be converted to the new nasty chrome model?
    Will any of them be neutered like in chrome? Like the useless “noscript” extension in chrome.

    Adblock Plus
    CanvasBlocker
    Disable Plugin & Mimetype Enumeration – Chrome hates privacy, no way of disabling these
    Disable Visited Links
    Disable WebRTC – Chrome do not wait on extensions to do their work so websites might load without security extensions!
    NoRedirect – Chrome do not support blocking nasty redirect tags
    NoScript – Chrome do not support real script blocking

    I can not live without these either:
    Greasemonkey
    Stylish
    DownThemAll!
    Tab Mix Plus

    Other of my extensions I’m worried about is:
    Hide BookmarksBar
    EPUBReader

    What the hell are you doing?
    Where have the original values gone of what Firefox should be.
    Since Mozilla got political with other nonsense Firefox have gone bad.

    What is it with forcing this shit down my throat: Hello, Pocket, Reader+, Share, Telegram, Tab Groups, WebRTC, etc.

  27. EH wrote on

    Hmmm…is seamonkey included in this change?

    1. Jorge Villalobos wrote on

      That will be up to the SeaMonkey Council to decide. If they want to continue basing their browser on Mozilla code, they will probably need to drop XUL like Firefox at some point (I should note that dropping XUL won’t happen for a long time).

  28. Nick C. wrote on

    Your review process takes 1+ weeks. With these changes you will have far too much workload to adequately handle all approvals.

    So as I read it you “will be” automating reviews. However. Shouldn’t you properly release the automation, and verify it’s working properly, before creating a backlog of work?

    Or do we need to start advertising Firefox will be breaking extensions, time to switch to chrome?

    1. Jorge Villalobos wrote on

      The automation process is already mostly working for unlisted submissions. On the listed side, we’re increasing our volunteer reviewer team significantly, and there are two new full time reviewers who will join us shortly.

  29. mike wrote on

    Don’t have a lot to say but with all the hate in the comments just wanted to let the devs know that not everyone thinks they are liars or fools or bringing the end times. It’s understandable why things have to change in a changing world. I appreciate the effort.

  30. tux. wrote on

    So we won’t be able to do the only thing other browsers don’t allow us to, namely completely recoding the user interface, anymore?

    We can’t have completely different tab bars or revamped, heavily customized Save As dialogs anymore?

    A pity. Goodbye.

  31. Arthur wrote on

    So, explain to me why I would continue to use Firefox over Chrome once these changes are implemented. Why would I still use it?

  32. Fred Fubar wrote on

    Comment probably will be lost in the commfog, but:
    One big reason for signing, deprecating XUL (sorry to see that name drop into the bin), &c is that TLAs are [ab]using FF as a surveillance platform. These changes are a Good Thing for those who care about privacy & security. I hope t\he commentariat has been paying attention since Snowden. FF & others have been reacting, not always to your benefit. Mozilla has been one of the few to implement changes that benefit YOU, not your Corporate Overlords.

    The concept of a common platform is great, and that you are working w/ Georgio on APIs to support NoScript is fantastic (in the sense that I will get NoScript for Chrome).

  33. A.A. wrote on

    No No No No No No No stop trying to be like Chrome

  34. top cuck wrote on

    I wouldn’t be as mad if the XUL stuff was replaced with similar low level APIs which provide the same functionality. But as it stands, it looks like you’re just destroying the possibility for addons to access this sort of thing which is utterly awful. I might move to Vivaldi for good, even though it’s proprietary trash.

  35. cry wrote on

    (ಥ‸ಥ)

    I can’t believe that this is really happening. Why is my favorite browser dying! Stop this! Why can’t you listen to your users? HELLO, I’m crying over here!

    The permissive add-on model can’t be a problem now suddenly, after being around for over ten years.

    Please read the Wikipedia article of the Add-on (Mozilla):
    https://en.wikipedia.org/wiki/Add-on_%28Mozilla%29

    Please, don’t redefine the meaning of add-on in Firefox.

  36. Klaus Hartnegg wrote on

    The list at http://arewee10syet.com is incomplete. While it does list some exotic add-ons with zero users, it does not list many others with thousands of users, eventhough they are on addons.mozilla.org.

    1. vertigoback wrote on

      I thought so, too. Do you have examples?

  37. Archie wrote on

    Well, removing XUL will remove the only reason I still stick with FF (the ability to remove tabbed browsing, which is a terrible UI concept). So long, and thanks for all the fish.

  38. Gylgamesh of Uruk wrote on

    I don’t like the idea of a multi-process Firefox.

    I don’t like that Firefox is becoming more and more like Google Chrome and aiming to become compatible with it or with Opera.

    Why can’t you people understand that diversity is good and that Firefox needs to keep its individuality as a browser and not become a useless Chrome clone?!

    Change is sometimes good, too much or too fast change usually ruins everything.

  39. trlkly wrote on

    The only way I can see you successfully getting rid of XUL (without hemorrhaging users) is if you come up with a JavaScript API that can mimic it entirely. To the point where someone could write a JavaScript tool to read XUL files and have it accomplish the exact same layout.

    I’m also rather disturbed not by what you say in the blog post but the implication that you are going to block out manipulating the chrome entirely. If you do that, there is literally no way you can get all the stuff extensions can currently do to port over. We have to be able to restyle using CSS (which is pretty dadbasted safe.) We have to be able to add toolbars. We have to be able to have addons like Tab Mix Plus with not only restyling but multirow tabs. I have to be able to make my own shortcut keys.

    There’s a reason Kmeleon didn’t work. It still had extensions, but they couldn’t touch the Chrome. The only reason it sorta works on Android is that people expect a mobile version to be stripped down.

    1. ben wrote on

      “We have to be able to restyle using CSS (which is pretty dadbasted safe.)”

      It isn’t if it tricks uses to think a UI element is something different than what it is.

  40. trlkly wrote on

    One more thing: when it comes to electrolosys, you NEED a mode where the shims don’t work. Heck, you need to be able to pref off different ones, or at least have an addon report what shims are being used.

    A lot of us are just trying to get the addons we like to work, and we don’t know them inside and out. I know that Keyconfig works on Electrolysis, and, once I get it signed, I expect to use it there. But I have no idea if it’s using shims or not.

    There are lots of addons that are widely used but aren’t being actively developed. Unless you make it easy for people to come in and make them work, Electrolysis is going to produce a worse experience for users, not a better one.

    I very much miss the Firefox that was going to use the fast release cycle and iterate changes gradually, instead of making huge changes that break a ton of things at once.

    1. Noitidart wrote on

      This is a great point, lots of addon devs are doing things they think are making it e10s friendly, but they might not understand everything and can be unknowingly using CPOWs, would be nice if there was some way to detect that.

    2. RDL wrote on

      trlkly – how near are you to getting keyconfig signed and will you please be kind enough to make sure that all of us can use it? Will you publish it on AMO?

      I think a lot of people are quietly desperate about the possibility of losing this extension.

  41. m48 wrote on

    I’m disabled. I depend on many functions of Pentadactyl to use the internet. If I can’t use Pentadactyl in Firefox, I will have to switch to a Firefox fork. And that won’t be from some sense of moral indignation. It will be because I will have to switch.

    Even if the WebExtensions API does support modifying the GUI extensively enough to make Pentadactyl possible, what does that change? I don’t know the details about how add-ons work in Firefox, but presumably, an extension that completely changes the browser’s GUI is deeply intertwined with XUL. Just how much of their codebase depends on that? Nearly all of it?

    So, let me get this straight.

    The authors of a Firefox extension that drastically improves the quality of my life are likely going to have to rewrite their entire codebase in a year… and I’m supposed to be happy?

    Because, what, it’s going to make Firefox development easier? For who? For Mozilla? One of the largest and best funded open-source projects in the world? Certainly not for extension developers, who are going to have to start nearly from scratch with much fewer resources. And, I’m sorry, but I have a little more sympathy for the extension developers. Am I supposed to believe it’s okay for Mozilla to make a community full of people with other jobs do thousands of hours of unpaid work for them because they don’t want to support their own mature extension framework? Work that will likely necessitate developers *removing* popular features that do not suit Mozilla’s business vision?

    If an add-on depends on something as insane as modifying Firefox’s code via regular expressions, fine, they deserve whatever they get. But am I supposed to believe that using the most common and powerful API for extension development is an act of similar heinousness? Am I supposed to believe that the only reason someone would want to arbitrarily modify Firefox’s GUI is that they are making “spyware and adware”? Who decided that I wanted to be “protected” from that?

    I would like to think Mozilla would take things like this into account, but I can’t help but imagine that these changes are going to impact disabled users much more than normal users. What do disabled users need in an extension? Modifications to the GUI and the ability to make Firefox communicate effectively with external accessibility software, right? XUL and XPCOM are the only ways to do this, right? And you’re just… getting rid of them? And our only consolation is that if developers lobby hard enough for features they already have, Mozilla *might* include less flexible, incompatible versions of them in the WebExtensions API?

    Was I being arrogant, as a disabled computer user, to expect more than screen reader support in my favorite web browser? Should I have expected, from the beginning, that if I had special needs, I would have to use a fork or be up the creek without a paddle?

    I don’t want my ability to browse the web determined by how much of a difference I make to Mozilla’s bottom line. And I definitely don’t want that justified by how much “safer” it’s going to make me. But that’s what it feels like has happened here.

    Maybe I’m being paranoid. But if I sound angry and frustrated and scared, it’s because I am. I no longer feel I have the luxury of thinking my way of life is safe. Apparently, I’ve got a time limit on how much longer I can browse the web like a normal person—roughly 12 months. After that, I’ll have to give up using a browser by a large, well-funded organization, and desperately hope that smaller projects like Pale Moon can keep pace with the breakneck speed of the internet.

    I don’t want to do that. I would like to stay with Firefox, and I would like to believe that Mozilla has the best interests of me and people like me in mind.

    But incidents like this have made me seriously doubt that.

    1. m48 wrote on

      (I, er, thought this comment got rejected by moderation, so I rewrote it, and there’s a… calmer version of it later on. You might want to read that one instead of this one. Sorry for being confusing, but I don’t think it’s possible to delete or edit comments in this system.

      I am, of course, still interested in what Mozilla plans to do for accessibility in the wake of this change, but I do not believe my tone here was entirely justified.)

      1. Kev Needham wrote on

        Passion is a good thing, and I appreciate you taking the time to write this. Thank you.

  42. John Constantine wrote on

    They need to have a modular API. Allow developers to create libraries to extend the API. These libraries would make Firefox updates MUCH more manageable, since the number of API libraries will be vastly smaller than the number of Addons in the AMO. These could be turned into community projects and contributed to by Addon developers.

    It would be best to have a Core API that developers can use for cross-browser addons. Then have an extended API for Addons that can only run in Firefox.

    Another idea…have hooks into the lower levels of Firefox through the API, but make it a permission based system.

    As for XUL, for starter a replacement could be modular dynamic HTML5 component overlays.

  43. John Constantine wrote on

    Regardless of what Mozilla decides to do, I hope my favorite Addons will be supported. Like:

    1. Tile Tabs (Very Important)
    2. Locationbar2
    3. Omnibar
    4. Open With
    5. Resurrect Pages
    6. Thumbnail Zoom Plus
    7. Tab Scope
    8. The Fox, Only Better

  44. John Stone wrote on

    I would just like to add a sort of “me too” comment to the concerns about addons. Specifically, the only reason I keep coming back to Firefox as my core browser in spite of it A) being much slower than Chrome for pages with lots of elements, and B) having a growing memory leak/cache buildup/whatever that eventually drags it to its knees and forcing me to restart it, is that the addons can “root” modify web pages. Prime examples: true adblockers that don’t even download the resources, MozRepl that allows me to automate testing, GreaseMonkey, etc. Chrome gets pretty close but it limits that last 10% of control that allows me to instruct the browser to do very specific things that help with my security exposure and content presentation which enhances my productivity.

    I’m not going to jump off the deep end and claim this is the death of Firefox per se, but to maintain your market share I suggest you work very closely with (by that I mean direct proactive support of) the addon builders (NOTE: specifically not “please see our new guidelines page”) to ensure that we can maintain the level of customizability and content control that we so greatly enjoy today. I realize that’s no small task, but I would highly recommend setting up some sort of addon dev contact that makes both technical assistance to and feature feedback from addon authors a responsive conversation. A consideration in that is that if addon authors decide there isn’t much point in maintaining a Firefox version of the addon that does basically nothing different than chrome, then they would be justified in abandoning the Firefox version. Unpleasant, to be sure, but not unreasonable.

    I appreciate the work you guys are doing in advancing the browser. I simply ask you consider carefully how much of a nerf you plan to hit addons with and what that will do to your most vocal supporters. 😉

    Kind regards,
    John

    1. Jorge Villalobos wrote on

      You win this thread, thanks for the feedback 😀

  45. Ryan wrote on

    I get it, and I think a lot of us do: individual freedom, security, and performance are often in tension with each other. But ‘RIP Firefox’ hyperbole aside, I think these comments do point to the significant segment of FF’s strongest fans who, when push comes to shove, would prefer a browser that puts freedom even ahead of those other things—and who don’t see major alternatives in the browser space other than FF who would support that choice. Please continue to work on improving security and performance of course—but we would really rather not see it come at the expense of any of the freedom that FF has spoiled us with over the many years that we’ve been enjoying it. Freedom to install any kind of extension we want, without oversight from any entity, however benevolent; freedom to customize deep details of how our browser works, even if it means shooting ourselves in the foot and introducing memory leaks or security holes. That’s the world we’d prefer to live in; that’s why we’re still with FF and not any of the alternatives. I hope you think about this change in that light, and not in terms of catching up on security and performance with your competitors.

  46. Ben Basson wrote on

    My initial reaction to this is that the add-ons ecosystem is going to suffer.

    Mozilla have a history of providing mediocre APIs that are poorly documented. It’s taken years for the Add-on SDK / Jetpack to finally get to a point where you can even do a handful of the things you could do with XUL and XPCOM – why should this new set of APIs prove to be any different?

    Let’s face it, even if Mozilla is willing (and able) to provide a stupendously amazing API set – it’s still not going to cover everything add-on authors have got in place right now, and add-ons are going to cease working.

    It’s too easy to say whether this is good for Firefox or not. Stability and performance over functionality is a gamble, and in my mind the wrong one. Firefox is already so fast as for any improvement to be imperceptible, but I’ll certainly notice when my add-ons are gone.

    1. Ben Basson wrote on

      * too early.

  47. Stefan wrote on

    I do understand the feeling on the part of Mozilla that something must be done. I work for a very large enterprise, and a significant majority of our users now use Chrome. It’s faster, generally speaking, and considered more secure. Personally, I hate it because I hate Google’s privacy track record, and because I hate the interface and some aspects of its functionality (or lack thereof).

    If it’s true that extensions like TMP will stop working forever, then there will be a lot less keeping me with Firefox. I hope they find a way to keep this from happening.

  48. Withheld wrote on

    “Those who surrender freedom for security will not have, nor do they deserve, either one.”

    ― Benjamin Franklin

    1. Noitidart wrote on

      We never sacrificed security though. Our review process was intensive. So I don’t see how security was ever an issue. Especially now with the signed addons.

      1. Withheld wrote on

        This famous quote has to do with sacrificing “freedom” _for_ “security”.

  49. Mike ThisIsCrazy wrote on

    No! No! No! Don’t do this to us!

    12 months, 24 months, 240 months – there is no way that all my favourite developers will redevelop all of their add-ons in any of these timescales!

    Please understand – it’s the extensions that keep FF unique, and keep us using it. If we loose them – and we will – and you become a Chrome clone, and it will be a very, very sad day for us, and a steepening of the slope to oblivion for FF.

    By all means add an API, but give US THE USERS the choice to either enable or disable XPCOM- and XUL-based add-ons. Yes, with a big warning, whatever, but don’t, please don’t ditch them!

  50. Chris wrote on

    I never thought I would see parallels between IOS and firefox. Enter the walled garden with a limited api that only core apps and features can escape. Your not making add-on development to be more like “Web development”, your making it more like IOS app development. Even Apple still allows unsigned apps on their desktop os, I think they know that their users would revolt, its strange that mozilla thinks theirs wont. Warning the user and even hiding it in about config is fine, please do not make xpinstall.signatures.required read only.

More comments: 1 2 3 4 5