Extension Startup
Key Goal
Avoid reading the Extension Manager datasource on startup.
In order to ensure a minimal impact on startup, we must avoid doing too much work before the application has started. Most of the initialization functionality that we want for extensions is either already supported today, or there is already a startup hook for it (component re-registration via .autoreg etc). We must avoid as much as possible adding additional complexity, especially reading a potentially large text/xml RDF datasource. There are some cases in which this is unavoidable - such as when a new extension is installed, one is enabled or disabled, an extension is uninstalled or a new version of the application is installed. These are all considered events less likely to occur at every startup, and thus a startup time penalty is acceptable.
There are two classes of extensions - application and profile. Application extensions reside in the application install folder and can be initialized before a profile is selected, profile extensions live in the user's profile folder (often this is the only place they have write access to) and can only be initialized after a profile has been selected.
From Launch to First Window
Extension initialization is encapsulated in a function called initExtensions, which can be called before and after a profile has been chosen, before for application extensions and after for profile extensions. Here is the timeline for calling both variants of this function:
- Application is launched.
- Extension Manager, registered as an app-startup listener in the category manager, initializes and application extensions are initialized.
- A profile is selected, and then profile extensions are initialized after the profile-initial-state notification is sent.
The extension initialization routine looks something like this:
- There are two questions that have to be asked - is an extension being installed/uninstalled/enabled/disabled? (i.e. are we going to have to load the Extension Manager datasource - and incur an acceptable startup penalty due to this), and are the current target application version and the version that the Extension Manager datasource has out of sync? (i.e. identify whether or not the user has just installed a newer version of the application).
- If the answer to either of these questions is yes, then the Extension Manager RDF datasource is read and the appropriate action is taken. See pseudocode in for some examples. In the case that the second question's answer is yes, then autoupdate is performed.
- If the answer on both counts is no, then the application can start without reading in the Extension Manager datasource. XUL chrome is already registered with the Chrome Registry from a previous start, so nothing needs to happen here, XPCOM components are already registered from a previous start, so nothing needs to happen there, and default prefs can be read in by either crawling the directory structure under extensions/, or by having the install procedure create a text file pointing at default prefs file folder locations.
-- Ben Goodger (2004/03/05)