XPCOM Startup

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.

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 significant change in binary compatibility and in some cases source compatibility. NSGetModule and nsIModule would be replaced with a single NSGetClassObject API. It is likely that NS_IMPL_NSGETMODULE would continue to work. I will need to audit the existing module implementations to determine whether module constructor/destructors need to be retained in some form.

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