Categories: Announcements Firefox

Component Directory Lockdown – New in Firefox 3.6

[This post originally appeared on Mozilla Developer News]

We hate crashes. When Firefox crashes, we try to get you back on your feet as quickly as possible, but we’d much rather you not crash in the first place. In Firefox 3.6, we are changing the way that some third party software hooks into Firefox which should eliminate a good chunk of those crashes without sacrificing our extensibility in any way. In the process, we’ll also be giving you greater control over the code that runs in your browser.

Background

Firefox is built around the idea of extensibility – it’s part of our soul. Users can install extensions that modify the way their browser looks, the way it works, or the things it’s capable of doing. Our add-ons community is an amazing part of the Mozilla ecosystem, one we work hard to grow and improve.

In addition to the standard mechanism for extending the browser via add-ons and plugins, though, there has historically been another way to do it. Third-party applications installed on your machine would sometimes try extend Firefox by just adding their own code directly to the “components” directory, where much of Firefox’s own code is stored.

There are no special abilities that come from doing things this way, but there are some significant disadvantages. For one thing, components installed in this way aren’t user-visible, meaning that users can’t manage them through the add-ons manager, or disable them if they’re encountering difficulties. What’s worse, components dropped blindly into Firefox in this way don’t carry version information with them, which means that when users upgrade Firefox and these components become incompatible, there’s no way to tell Firefox to disable them. This can lead to all kinds of unfortunate behaviour: lost functionality, performance woes, and outright crashing – often immediately on startup.

In Firefox 3.6 (including upcoming beta refreshes), we’re closing this door. Third party applications can still extend Firefox via add-ons and plugins the way they always could, but the components directory will be for Firefox only.

What Does This Mean For Me?

If you’re a Firefox user, this should be 100% positive. You don’t have to change anything, your regular add-ons should continue to work properly – you just might notice fewer crashes or odd bugs. If you do notice that something has stopped working, particularly a third party addition to Firefox, you might want to contact the producer of that addition to ensure they know about the change.

If you’re a Firefox component developer, this shouldn’t be a big change, either. If you’re already packaging your additions as an XPI, installed as an add-on it’s business as usual. If you have been dropping components directly, though, you’ll need to change to an XPI-based approach. Our migration document on the Mozilla Developer Connection outlines the changes you’ll need to make, and should be pretty straightforward. The good news is that once you’ve done this, your add-on will actually be visible to users and will support proper version information so that our shared users are guaranteed a more positive experience.

If you haven’t downloaded the new Firefox beta yet, and want to give it a spin, you can find a copy here.

Johnathan Nightingale
Human Shield

14 comments on “Component Directory Lockdown – New in Firefox 3.6”

  1. David Naylor wrote on

    Woah, huge user win.

    No more shady deals when installing other software. At least not with Firefox add-ons bundled.

    Being in control is one of the main reasons for using Firefox, and that just got even better with this change.

  2. Babua wrote on

    ff 3.6 final has also been crashing frequently in my Windows 7. About 20 times today. It is a very poor show. I installed the latest version today only.

  3. Daniel Veditz wrote on

    Firefox 3.6 has not been released yet, you do not have “ff 3.6 final”. Keep reporting those crashes: that’s how we know which ones are the most important to focus on. If you’re crashing 20 times a day, though, you’re suffering from some software incompatibility between Firefox and something else on your system. Please visit the forums at http://support.mozilla.com and they can help you figure out what’s going on from you reported crashes and probably help you identify the culprit.

  4. Daniel Veditz wrote on

    To put “20 times a day” in perspective that’s about how many crashes we’re currently seeing from a few hundred 3.6 Beta users put together.

  5. Dis Gruntled wrote on

    Once again, Mozilla shows love to their large developer base by easing in a significant change thru a tried-and-true deprecation process, whereby developers are encouraged to make the necessary changes over a period of time, many months in advance of Firefox dropping a key feature.

    Wait… um… OK, scratch that. Nevermind.

  6. Daniel Veditz wrote on

    In what other application is it normal to modify their installation directory? We have published for years several appropriate ways to extend Firefox and this was not one of them. It happened to work, but it was never a supported way for 3rd parties to modify a Firefox installation.

  7. Zetaprime wrote on

    Is there anyway to disable this feature? I’d like to be able to decide which addons I can keep and not have Firefox tell me I can’t use them. I already had to uninstall 3.6 beta 3 and go back to beta 2 to get my addons back. Let me decide if I can live with a certain degree of instability in exchange for the functionality many of these addons provide.

    1. Daniel Veditz wrote on

      This feature is not about addons, this prevents 3rd party software from hooking into Firefox in a way that is guaranteed to break (and does) at the next major update. Possibly on a minor update for binary components depending if they were using an interface we had to patch. This was never a recommended or even documented mechanism for extending Firefox, and we’ve found a large percentage of the crashes experienced by Firefox 3.5 users is due to 3rd party components hooked in this way.

      Plugins and Addons hooked in through the documented places certainly do cause their share of stability problems also, but since it is possible for users to know about and manage them we do let you make your own tradeoff between functionality and possible instability.

  8. Daniel Veditz wrote on

    I read too quickly and assumed you were talking about this blog post, but you were talking about addon compatibility version checks which is something else entirely. Beta users do sign up for a little pain in that regard, but you can help if you like by using the Addon Compatibility Reporter which will reenable all of your addons and let you report which ones work and which don’t.

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

    Or you can wait until after we ship 3.6 by which point most of the addons should be compatible.

  9. markafoni davetiyesi wrote on

    Firefox 3.6 has not been released yet, you do not have “ff 3.6 final”. Keep reporting those crashes: that’s how we know which ones are the most important to focus on. If you’re crashing 20 times a day, though, you’re suffering from some software incompatibility between Firefox and something else on your system. Please visit the forums at http://support.mozilla.com and they can help you figure out what’s going on from you reported crashes and probably help you identify the culprit.

  10. OuT wrote on

    Hi,

    QuickTime still copies nsIQTScriptablePlugin.xpt into the components dir… how this case will be handled ?

    Regards

  11. Daniel Veditz wrote on

    OuT: The change here does not stop programs from copying files into the component directory. They shouldn’t have been doing so (there are several well-defined mechanisms by which they can add their stuff that don’t involve mucking with the installation directory of another product), but acknowledging that they do we simply don’t load components that were not built with the product.

    .xpt files are simply data structures describing interfaces, they are not executable code. If we don’t load the associated components then those interfaces will not be used.

  12. OuT wrote on

    I know nsIQTScriptablePlugin.xpt will still be copied, but simply ignored, and won’t block essential QT stuff. Nevertheless Apple has to fix this.

    By the way, could you tell me a concrete application of XPCOM with QT ? I cannot find anyone… I’m also searching for an application of XPCOM with Flash Player (flashplayer.xpt, it used to be installed directly in components dir, some time ago).

    I’d simply like to know the purpose of these components 🙂

  13. Home Security Cameras wrote on

    This sounds like a great idea. Not that Firefox crashes often on my Mac anyway, but I have had issues with extensions, on a few occasions after a crash.