Extension Manager:API Rewrite: Difference between revisions

The new API is accessed through a global [[Extension Manager:API Rewrite:API#AddonManager|AddonManager]] object that is included in a JavaScript module. There will also be a limited amount of access provided through an XPCOM component but this is intended for the XRE to use during startup. The API makes no assumptions about what different types of add-ons do and how they are used, it does make some basic assumptions about the information available about them and the install process. Users of the API can register to receive events about all add-ons.

Underneath the manager (and essentially invisible through the API) are a set of add-on providers. Each one manages a specific type of add-on, for example there can be a provider for XPI style add-ons, a provider for plugins, a provider for lightweight themes, etc. There will probably be a hardcoded set of providers for the application and then some means for add-ons to register their own providers. It is up to the providers to maintain their lists of installed add-ons, perform installation and uninstallation and send appropriate notifications out to registered listeners.

Certain add-ons may have restrictions over what operations can be performed. These restrictions could be just down to the nature of the add-on (themes cannot be disabled normally) or down to system policies (user's may not have access to uninstall some add-ons f.e.). Each Addon has a permissions property that indicates what operations can currently be performed.

Some types of add-ons may require restarts for certain operations. XPI style extensions for example require restarts for almost all operations. The API exposes the operations that are pending in the pendingOperations property. It is also possible that this property may be used to indicate operations that have been deferred for any reason, maybe timing issues, maybe a dependency is pending install. Pending operations can make it hard to tell what state an actual add-on is in. To help solve this the isActive property indicates whether the add-on is currently active. This is separate to and may be different to the various userDisabled, isCompatible and other properties that indicate whether an add-on can be active or not.

;Downloading :This state is used to show that downloads are in progress for the add-on. Almost all add-ons consist of a single file to download. Once the file is downloaded the Checking state may be entered if additional information is required, otherwise the Downloaded state is entered.

;Checking :In some cases the additional information about version compatibility and dependencies may be required. The Checking state is used for small lookup requests for these and then dependent on the result the AddonInstall may move back to the Downloading state or on to the Downloaded state.

;Downloaded :At this point all the necessary parts of the add-on are available on the computer. It is here that the user may be asked if they want to proceed with the installation.

Once the install process for an AddonInstall is started with <code>startInstall</code> it will move through all of the states naturally sending out notifications at each transition and some progress events in between until either an error is encountered or the install is stopped by calling <code>stopInstall</code> or the install completes successfully.

Certain types on installs may skip steps. Installing an add-on from the file system for example may jump straight to the Downloaded (or Checking) state since there is no need to download it.