Extension Component Registration
Firefox's new extensions system allows each extension to supply its own set of XPCOM components in its own components directory. This is to allow extensions to create their own components that do not interfere with the application's components directory. (Basically we don't want extensions installing files outside of the file hierarchy described in other documents.
Two problems remain -
- The component registry (compreg.dat) lives with the application in an area of the system that the user may not have permissions to write to, so the benefits of caching profile extension components is unavailable,
- There is no scheme for handling the removal or disabling of an extension and its components, if such an event causes the removal of component registry entries and subsequently removes entries set by the application's versions of those components, there is no way to restore those entries.
Proposed Solution
Consider the Component Registry as a cache, a cache that prevents component registration via scanning at each start. Since the new extension system proposed offers profile components, components could be in the profile directory as well as the application directory. The compreg.dat file is thus a cache of all of these sources, and should reside in the profile folder with other caches:
<profile>/compreg.dat
<profile>/extensions/* <-- Extensions Structure
Since the component registry is a registration cache of components from the application components folder, the application extensions folder and the profile extensions folder, it belongs in the root of the profile, rather than in the extensions folder.
If no profile is specified (and there is more than one profile), XPCOM is started and the profile manager UI shown. When a profile is selected XPCOM is shut down and restarted with the correct registry. When there is only one profile or the user specifies one from the command line, the profile is known early enough (i.e. it is a parameter to main()) to locate the component registry during XPCOM initialization. Restarting Geck could even mean re-launching the application with the selected profile as a command line argument.
Registering Extension Components
When a new extension is installed that supplies components, the extension manager places a .autoreg file in the profile directory that forces the component registry to be erased and re-generated at the next startup. This is an acceptable cost to incur as extension installation is not frequent.
Uninstalling/Disabling Extensions
When an extension is uninstalled or disabled through the front end, the removal can only be done at the next startup since components and front end overlays cannot be unloaded dynamically.
When an extension is uninstalled the extension manager can write to a text log file identifying the paths to extension components folders that are not to be registered at the next startup. An .autoreg file is then placed in the profile directory. At the subsequent launch the component registry is regenerated and the uninstalled/disabled extensions are not registered, but all the others are.
This solution gets around problem 2 identified above - when an extension overrides an existing component, the application's version of the compnent is re-registered after the extensions is uninstalled because the component registry is always regenerated after an uninstall/disable event.
Notes
The Component Manager would need to know to scan in
<profile>/extensions/<extension>/components/*
-- Benjamin Smedberg, Darin Fisher, Ben Goodger, et al.