XPCOM Startup
(Note - this change has landed on mozilla-central! Benjamin helpfully came up with a list of changes you'll need to make to your code)
In Firefox 3.x, XPCOM initialization is programmatic, and component registration is a one-time event. This leads to several problems which we'd like to solve for Firefox 4:
- The content process startup (OOP tabs, Fennec and eventually Firefox) either trolls the filesystem at every startup and tries to save registration data in the hopefully-readonly application dir, or needs extra code so that it shares a fastload cache with the chrome process (difficult/racy/error-prone)
- Whenever the extension manager (at startup!) detects that the list of XPCOM components may have changed, it invalidates all component load information and double-starts the application, leading to the dreaded dual-start feature which kills startup performance and makes debugging difficult (and has unfortunate UI consequences)
bsmedberg's proposed solution has multiple pieces.
Contents
Part A: data registration, not programmatic
XPCOM component registration should normally perform only the following tasks:
- map a contractID to a CID
- implement a CID
- add category entries
Instead of using a programmatic callback (nsIModule.registerSelf), components should export their registration as static data tables. The precise form of these tables is TBD: I'd like to just use chrome.manifest for all the data in extensions, and binary exports for libxul/DLLs.
The category manager would no longer by dynamically mutable, and would use read-only methods.
This is a change in both binary and source compatibility. NSGetModule and nsIModule would be replaced with a single NSGetFactory API.
Part B: only libxul components for the content process
Don't use any sort of fastload cache for the content process. Only make components which are built into libxul available in content processes. Message-manager scripts should be cached/fastloaded by the chrome process and shipped over as blobs, if necessary for performance.
This means that XPCOM components (JS or binary) from the application (Fennec) or extensions would not run in the content process.
Part C: Get rid of the EM restart
Instead of a single startup sequence where all components are instantiated immediately, startup would use the following sequence:
- register builtin and application components
- query the extension manager and allow it to perform install/upgrade/uninstall tasks
- load extension components as necessary
