I ended up volunteering to architect the localization of Firefox 1.0 and beyond into the new toolkit. This is not a small undertaking, but it looks to be relatively manageable on the aviary branch, since I don’t need to worry about breaking seamonkey on the branch.

The consensus between developers is that we need to get the localizations into the CVS repository. This will help with quality control and openness, and perhaps help companies that base products from the mozilla codebase to benefit from localization efforts. In addition, we need to collect all the en-US locale files that are scattered throughout the tree into a small set of locations. These will be:

toolkit/locales/ab-CD
browser/locales/ab-CD
mail/locales/ab-CD

“pseudo-extensions” (xmlextras) that are actually part of the toolkit will be moving into the toolkit directory. “Real extensions” (DOM inspector) will be localized in their own tree (extensions/inspector/locales/ab-CD).

I hope to blog regularly with updates, as I make progress and make decisions. There are still some leftover issues with how the installers are going to be shipped. We want to strike a balance between not forcing leaf to build 10-20 releases, and not having a single release with all localizations in it, which has the possibility to be quite bloated.

To facilitate the transition, I am adding support for preprocessing jar.mn files. Please do not use this feature unless you are aware of the issues (in particular, don’t use platform-specific #ifdefs in jar.mn files… it causes havoc when you start to ship language packs).

Most mail readers have a feature by which incoming messages can be sorted into categories (folders) based on characteristics of the message, such as the sender, the mailing list it was sent to, the priority assigned to the message, etc. The rules defining this sorting process are called “Filters” by Mozilla Mail and “Message Rules” by Outlook Express. These filters/rules are generally quite static; if you are computer-savvy enough to figure out how to create a filter, you set it up and leave it alone. However, I have found that static filters frequently do not meet my needs: I want to manually sort messages into various folders, and then have the mailreader filter all replies to these messages into that same folder. For example, I am currently involved in 100+ Mozilla bugs, divided into several general categories:

semi-single-profile/firefox 0.9
xulrunner/mozilla-the-platform
xpinstall/installer (mainly as a reviewer)
build config (random crap)
RDF implementation bugs and API redesign

I want the ability to sort messages from two mailing lists, several newsgroups, private mails, and bugmails into folders for each of these categories. I don’t find it especially onerous to drag the “first” bugmail, private mail to the subfolder. But after that, I want all subsequent mails to be auto-sorted into the correct category.

It doesn’t seem to me that this would be especially hard, if we’re only discussing email. Newsgroup messages are a lot harder to handle in this scheme. Maybe I’ll break down and use the mailing-list versions of the netscape.public.mozilla.* groups instead.

P. S. I also want the view-sorting mechanism to be smarter; my preferred view-sort would be “threads with unread messages first, and then threads sorted by the newest message in the thread.”

Part of the mozilla2.0 project is providing generic support for running XUL applications. This has been known by various names, including the XRE and the apprunner. The current way to run a XUL application is to run mozilla.exe -chrome <url>. However, this is a poor solution for several reasons:

1. Apps have little/no control over command-line param handling (the default handlers installed by the mozilla app are always active)
2. Apps have little/no control over window icons.
3. Apps have to use the mozilla profile, and have odd or no control over remoting (xremote/DDE/appleevents)

The solution to this is a dedicated program to run XUL apps. This “xulrunner” will run XUL applications, from the smallest one-file applications to the largest apps such as firefox and thunderbird.

The first steps for the apprunner will be basic. However, I (and others) intend to work the xulrunner to a feature-complete solution within the next six months. There are several feature requirements for a full-featured xulrunner:

• Apps must be able to integrate with the OS/shell in an cross-platform way. This includes file assocations and icons, “start menu” icons, and desktop/quicklaunch icons.
• Native uninstall support on windows.
• App must have the option of running with shared preferences for all gecko-based apps.
• The app will have the option of running with it’s own app-specific profile, or no profile at all.
• Finally, I’m doing a simple GUI builder/packager to automate the app-building process. As a first step this will not do GUI XUL editing, only “packaging/building” using a wizard-like interface.

As a second step, I would like to give the xulrunner the ability to run apps in a restricted security space. This might involve some major backend changes to how mozilla handles security contexts (more on this later).

I have just landed semi-single-profile on the firefox trunk. It will probably take a couple days (or more) to settle out the major regressions in the startup code. It will probably take even longer to settle out the interesting problems with the extension manager (it’s a totally-new functionality, and it’s hard to debug).

When reporting bugs, please make sure to say what version (trunk or branch) you’re using, and what the build date is. Please also search for existing bugs carefully… I have been surprised at how many duplicates are files of firefox branch bugs for 0.9.

Right now, we are using the same restart mechanism on the trunk as we did on the branch. On most platforms (except Mac) this involves using execv to replace the current process. On mac, it turns out that execv doesn’t work for bundled apps, so we have to use trickier system calls.

This is going to change, relatively soon. I have been working at making XPCOM re-startable, so that you can call NS_InitXPCOM2/NS_ShutdownXPCOM several times over the life of the app. This is more “dangerous” because of static data in the tree that might not be cleaned-up properly during XPCOM shutdown.

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.