Starting with Firefox 3.6, only well-known components shipped with Firefox will be loaded from the application components directory.  Any other components (both binary and script) will be ignored.  This work might also be backported to the 3.5 branch, but that decision has not been made yet.  There are a number of reasons why this decision was made.

Firefox, through Gecko, has always had a flexible component-based architecture.  In particular, creating binary components to interface with the OS or with other applications is fairly straightforward, though ultimately dangerous.  Binary components have full access to the application and OS, and so can impact stability, security, and performance.  What’s worse, in a binary component, the line between supported/frozen and completely unfrozen internal Gecko interfaces is blurred, making it easy to create a binary component that works well against one very specific version of Firefox (potentially as specific as a minor security release), but causes serious problems with any other version.

As we’ve seen the popularity of Firefox increase, more and more binary components have been written to interface between Firefox and other applications.  However, we haven’t provided great guidance about the appropriate way to do so.

The only supported way of adding functionality to Firefox (whether a binary component is required or not) isthrough an add-on. This has many advantages for users: they can see that additional functionality is installed in the Add-ons Manager, and from there they can easily enable or disable it, as well as check for and receive updates.  We’re working on improving the user experience when third-party addons are installed in system-wide locations.  Also, critically, add-ons include information indicating their compatibility with specific versions of Firefox.  Having this version information allows for safe upgrades, especially when binary components are present.

Currently, third-party applications can drop binary components into the Firefox application’s components directory and expect them to be loaded as part of our normal startup.  This causes a number of problems, not the least of which is the removal of the user control that add-ons provide.  Unfortunately, a number of third-party applications are using this approach to integration, and are currently causing Firefox 3.5 users stability problems.  Many of these components were written for Firefox 3.0, and have not been updated for Firefox 3.5; a situation that we have no way of detecting because of the lack of versioning information on these “bare” components.  Because a number of internal interfaces changed between the two versions, this leads to crashes or other problems when these components are used.

In order to simplify future integration with native code, Firefox 3.6 will include support for JSCtypes for add-on developers.  This approach is greatly preferred over writing binary components.  For example, a third-party component that would like to perform some action implemented in native code when an event is received can write the integration pieces in Javascript (capturing the event and so on), and use JSCtypes to make function calls to regular non-XPCOM component native code.  Keeping as much of add-on code in Javascript reduces the impact of internal changes to Firefox, and allows for much easier maintainability.

(If you are a third-party application developer and have questions about integration in Firefox, please contact me — I’d be happy to put you in touch with the right people who can answer questions and provide guidance.)