Extension Manager:API Rewrite

Overview

The current extension manager API is focussed on managing XPI style add-ons and is currently very limited forcing the UI and other callers to rely on direct access to the RDF datastore to glean certain required information about add-ons.

The main goals of this rewrite are:

• Support a wider range of add-on types managed through the same interface
• Allow application/extension developers to be able to easily query the state of installed items
• Make it easier for applications to replace the add-ons UI with their own implementation
• Simplify the internal code and speed up startup times
• Minimize the use of RDF throughout the backend
• Remove direct access to the datastore

Add-on states

The new APIs represent add-ons in a number of states but these can broadly be split into two types, Local add-ons and Available add-ons. The API objects representing these add-ons are considered live views of the add-on. As operations are performed (disabling, downloading etc.) the properties of the object will update to reflect the new state. The objects represent add-on instances however. If I have an object representing the installed add-on "foo", then the user uninstalls and then reinstalls "foo" then the object still represents the old uninstalled instance of "foo". It is undefined whether retrieving the same add-on from the API twice will give two references to the same object or two separate objects that have the same properties.

Local add-ons

Local add-ons are add-ons that have been installed, or are installed but pending an application restart to be activated.

The majority of the fields available are expected to be self explanatory however a couple deserve special mention:

isActive

This indicates whether the add-on is currently active in the application. For XPI style add-ons this cannot change without a restart, for other add-ons it may change instantly as the add-on is enabled/disabled.

availableUpdate

When an update to the add-on has been detected this is set to the information about the updated verson.

pendingUpdate

When an updated version of the add-on has been downloaded and installed, but the install requires a restart, this will give a reference to the new version.

pending*

Whenever an operation is waiting for an application restart to complete one of these flags may be set.

checkCompatibility

This method is similar to isCompatible however it allows checking compatibility with a particular version of the application. This is necessary for the application update system to determine whether new versions of add-ons are necessary before an application update.

It is expected that certain types of add-ons will implement an additional interface to provide specific methods/attributes. For example XPI add-ons will need to expose a method to get access to the installation files as we currently do through the nsIInstallLocation interface.

Available add-ons

Available add-ons are add-ons that are known to be available somewhere. This may include:

• Add-ons offered for install by a website
• Updated versions of add-ons detected by the update system
• Add-ons on the local filesystem the user is trying to install

Available add-ons also go through a number of states between simply being known as available, through downloading and on to installing.

The fields of the extIInstall interface are filled out depending on the available information. Some install methods for example do not give any information about the name or version of the add-on being installed.

addon

This is an overloaded field. If the extIInstall represents an update to an existing add-on then the addon field references the old version of that add-on. After the available add-on has been downloaded and installed however the addon field references the installed add-on.

certificate

If the available add-on's code has been signed then this will hold the certificate. This may not be available until after downloading has begun/ended.

Consider splitting the addon field into two separate fields

Management

The global management interface is a lot simpler in this API. Essentially it only contains methods to start installs, list local add-ons and available add-ons, and adding various listeners to be notification about important events.

Need to decide whether pending installs and/or pending upgrades appear in getAddons. They have to be reachable somehow but presumably they are through getInstalls although indirectly.

Additionally there is a need for a private interface to the manager. This is only to be used by the platform and other internal components in order to facilitate add-on loading and blocklisting. The actual content of this is likely not as it stands here, this is just a copy of the existing internal methods from nsIExtensionManager

Listeners

In order for the UI to be kept up to date with the state of add-ons and installs there are a number of listeners that can be registered for. These are split into three types.

Local add-on events

These events are focused on local add-ons and allows the UI to change state as the add-ons are enabled/disabled/etc.

I think there are additional events we are going to need here.

Available add-on events

These events cover the progress of detecting, downloading and installing available add-ons.

Update check events

When performing an update check the following listener will receive events about the progress of the check.

onUpdateAvailable

This will indicate an available add-on that is compatible with the application version that the update check was performed for.

onCompatibilityUpdates

This indicates that the local add-on that an update check was performed for received a compatibility update during the check.

onUpdateFinished

This is always called at the end of the check and indicates whether there was a success or failure.

We might consider having onUpdateAvailable be called for every available add-on, callers could then decide which of the available new versions to install.

Implementation

It is expected that the extension manager code will be split into multiple parts consisting of a central manager that doesn't have very much functionality and then a number of separate components to manage different types of add-ons. It's not defined how the manager will interact with the separate components but presumably we will either make them separate xpcom components with a well defined interface, or use jsm modules. Presumably the separate components will need their own datastores for their own specific needs, however we might consider having them all share a single sqlite database.

The central management code will have to be written, likely mostly from scratch but this is just a thin wrapper around the separate components. The existing XPI management code can be reused to make up the separate component handling XPI add-ons. The UI will also have to be rewritten to use the new API rather than the RDF datastore.