I’ve been working for the past several months on a project for the new Mozilla toolkit called “semi-single-profile”. This project involves significant changes in the startup sequence of the browser. Now that we have branched for firefox 0.9 and 1.0, this project has landed on the branch.
This has caused some build-bustage and some questions from the Firefox community about the “why” of the project. I wanted to give a brief explanation of the benefits.
When seamonkey starts, it launches XPCOM very early in the startup process, before the profile location is known. This means that you have to keep compreg.dat and xpti.dat in the application directory.
This is not a good solution when there are extensions being installed. Extensions can (do) add entries to compreg.dat and xpti.dat that may be incompatible with other extensions. In addition, if you install extensions into your profile, you can have extension information “leaking” between different profiles.
To solve this problem, we need to move the compreg.dat and xpti.dat files into the profile. However, you must specify the location of compreg.dat and xpti.dat when you call NS_InitXPCOM2… you cannot wait until you have a selected profile.
The basic idea of the semi-single-profile patch is to select a profile before launching XPCOM. However, there are situations which make this complicated: Thunderbird has a requirement from commercial consumers that it support multiple profiles. Therefore, we can’t just hardcode a profile path like Application Data/Firefox/profile. The profile-migration features of Firefox also have special requirements about selecting and launching profiles.
I therefore rewrote the startup sequence of the new toolkit (nsAppRunner.cpp). The major problem is that (on the branch at least) we are not allowed to start XPCOM more than once in the same process; there is too much static data in the codebase which doesn’t get cleaned up properly. (On the trunk, we are going to use an xpcom-restart solution).
If Thunderbird needs to show the profile manager UI, or if Firefox need to restart the app for the extension manager, the app will launch a child process (clone) of itself. This is causing a little bit of grief with the tinderboxen and debugging, but we’re working on fixing it.