Extension Manager:Overview

This page gives an overview of the extension manager component focusing on the elements in nsExtensionManager.js.in and proposes some refactorings that can help improve performance, reduce code complexity and expose more functionality to developers.

The goals of the extension manager are:

• To allow the user to install add-ons
• To allow third-party applications to integrate add-ons
• To allow the user to enable/disable/uninstall add-ons
• To let the user know that updates are available to add-ons and to install them.
• To tell the XUL runtime what add-ons are installed so that it can load components and chrome from them

This overview is correct as of Gecko 1.9.1 though it should go without saying that it is in some places a simplification to ease understanding and the source code is the definitive guide to specific behaviours.

Dramatis Personæ

Code Players

ExtensionManager plays the main role of nsIExtensionManager as well as the lesser roles nsIObserver and nsITimerCallback

ExtensionsDataSource is a tour de force as the middle-man between the rest of the code and the RDF based datasource holding the add-on meta-data.

DirectoryInstallLocation and WinRegInstallLocation play the lesser parts of nsIInstallLocations, the latter only appearing in the Windows performance of this piece.

InstallLocations plays a singleton role maintaining a list of known install locations.

PendingOperations, also a singleton, remembers any operation that is waiting to be performed for each add-on.

StartupCache is a singleton as well and is used to read and write the extensions.cache file.

File Players

extensions.rdf appears in the profile and holds all known meta-data about installed add-ons, drawn from their install manifests as well as subsequent update checks and disabled state.

extensions.cache also appears in the profile and remembers the last modification time of each known add-on as well as any operations waiting to be performed.

extensions.ini is in the profile as well and keeps the final list of what add-ons are enabled, allowing libxul to know where to load components and chrome from.

Character Interactions

General Overview

The extension manager is a regular xpcom component. Its job is to manage the list of installed add-ons. Every add-on is installed in an install location (represented by a nsIInstallLocation).

An install location simply contains a list of add-ons registered with it and where the add-on's files are stored. There are currently two types of install locations, the most common is the DirectoryInstallLocation which exists as a single directory in the filesystem. All registered add-ons appear inside this directory as directories named after the add-on's ID. The other type is the WinRegInstallLocation which only exists on Windows. This looks for add-on registrations in the windows registry, the add-on's files can be held anywhere on disk.

Install locations have priorities. If the same add-on (as determined by ID) appears in multiple install locations then the actual instance used is the one in the install location with the highest priority.

The install locations vary between platform, and since custom locations can be registered potentially by application too, however the normal platforms see 4 (OSX) or 5 standard install locations.

In general whenever the working set of add-ons changes (either through install, upgrade, enable, disable or uninstall) then the application must be restarted to ensure chrome and components are loaded/unloaded from the relevant add-ons. The main exception to this is for themes which aren't the currently used theme. The procedure followed is to mark the changes necessary in the startup cache and then after restart perform the necessary operations and then restart the process again to bring the changes into effect.

Platform Interactions

The XUL platform interacts with the extension manager during startup to allow any pending operations to complete and so to update the working set of add-ons. More specifically the following sequence occurs during a startup:

1. nsAppRunner selects the profile for this run of the application and dispatches profile-after-change to the EM
2. This initialises the EM, loads registered install locations and necessary settings from the preferences.
3. nsAppRunner checks the command line for -install-global-extension and -install-global-extension, if either are present it calls the EM to install the items into the application install location.
4. If the application version has changed since the last run with the current profile then nsAppRunner calls checkForMismatches so the EM can perform any necessary migration and check whether any items should be enabled or disabled due to the application version change.
5. nsAppRunner calls start for the EM to perform any pending operations. Depending on the result of this startup will either continue or a restart will be performed.