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.

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.