XULRunner

Overview

The goal of the XULRunner application is to provide a lightweight container application that can be used to bootstrap XUL+XPCOM applications that are as rich as Firefox and Thunderbird. See also libxul .

What's in XULRunner?

XULRunner should basically be Firefox without everything under the browser/ directory. That means that it includes all the core XP toolkit code that Firefox and Thunderbird currently share, including the Extension Manager. What is finally included in XULRunner is of course entirely up for debate, but the plan is to make it be some useful subset.

As we proceed down this path, it is quite likely that we will encounter components under mozilla/toolkit that do not make sense as part of XULRunner. These may be too browser specific or too mailnews specific. The goal is to migrate these pieces out of toolkit, and into app specific directories. We'll see how well this goes ;-)

Also, a core requirement of XULRunner is the elimination of any app-specific #ifdef's. It does us no good if portions of the toolkit are #ifdef MOZ_PHOENIX. (See bug 285789).

User Profiles

An application running on top of the XULRunner has a fully "managed" profile directory for storing user specific data. XULRunner sets up the profile directory for applications automatically, and it uses the same profile locking mechanism used by existing applications like Firefox and Thunderbird.

The profile directory for an application is created under vendor/appname in the appropriate place on the user's system. For example, under Windows this would be:

$USERPROFILE\Application Data\$vendor\$appname\Profiles\$random.default

And under Unix systems it would be:

$HOME/.$vendor/$appname/Profiles/$random.default

Where $vendor and $appname are chosen by the XUL application, and $random is generated by XULRunner to obscure the location of the user's profile data.

The goal of this approach is to eliminate the need for the application developer to think about profile details. The default configuration should simply work without much fuss.

Down the road, we will want to allow XULRunner-based applications to participate in profile sharing. The goal here is to allow applications to share data that is common to the web platform such as SSL certificate, cookies, and the web cache.

Where's development happening?

Development has now moved to the trunk. See bug 257162 for details. It is known to build under Linux (and Windows with some minor hacking in toolkit/mozapps/installer).

How do I build it?

Building XULRunner is a lot like building any other Mozilla application. Start by pulling client.mk from CVS:

$ cvs co mozilla/client.mk

Setup a mozconfig file. Here's what mine looks like:

$ cat $MOZCONFIG
export MOZILLA_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1

mk_add_options MOZ_CO_PROJECT=xulrunner
ac_add_options --enable-application=xulrunner

If you want to build debug, then include these options:

ac_add_options --enable-debug
ac_add_options --disable-optimize

If you are building on Linux, then you'll probably want to add these options as well:

ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-xft
ac_add_options --disable-freetype2

Ok, I built it. So, now what?

Try running the sample XULRunner application:

$ cd dist/bin
$ ./xulrunner apps/simple/simple.xulapp

Not much to see, I know. But, take a look at the contents of the apps/simple directory. Pretty simple (for a Mozilla-based app), wouldn't you say? Check out simple.xulapp

Versioning

XULRunner is a delivery vehicle for the XUL toolkit, which is not a frozen API. It is an API that has historically evolved over time, and it will likely continue to evolve for some time to come. While people agree that we need to stablize that API, it will not happen overnight.

For these reasons, it is important that XULRunner support applications that require specific versions of the toolkit. The current thinking is that XULRunner will be versioned (with version number matching the corresponding Gecko milestone), and applications will be able to specify the version(s) of the toolkit that they require.

This is in fact already implemented as options in the .xulapp file. Applications can specify a MinVersion and MaxVersion for the toolkit versions they require. XULRunner will refuse to load an application that does not pass the version test.

Some relatively old notes: XUL:Xul_Runner_Versioning

What needs to be done?

XULRunner bugs

TODO: turn this into a bug list

RESOLVED -- This problem has been completely eliminated by bsmedberg's patch for bug 278534. That patch makes it so that XUL app authors never need to write resource://app/. Need to improve the way we specify resources in the application directory. Currently, this is done with resource://app/path/to/some/file, but bsmedberg points out that it might be better to make resource:///path/to/some/file point into the application directory. This requires coming up with a new resource key to specify resources located in the XULRunner directory. "xre" or even "gre" come to mind. We settled on resource://app/ afterall.
RESOLVED -- This problem has been completely eliminated by bsmedberg's patch for bug 278534. That patch eliminated chrome.rdf. Need to write out chrome.rdf for chrome files located in the application directory. Currently, XULRunner looks for chrome/installed-chrome.txt in the application directory as well as in XULRunner's directory. bsmedberg suggests persisting the chrome registry in the profile directory instead of trying to manage multiple chrome.rdf files. We decided to use the chrome.rdf in the profile for chrome files under resource://app/chrome/.
TODO -- Verify UA string. Need to make sure that there is a clear distinction between the application's {name, buildID, version} info and the corresponding info for XULRunner itself. For example, the UA string still needs to be generated properly.
TODO Static references to the application name may be an issue. For example, mozilla.in needs to know the vendor name and application name in order to locate the profile-relative init.d directory. These strings can't be statically defined anymore. Do we really care that much about init.d stuff? The init.d stuff is currently not supported.
RESOLVED -- bsmedberg's rework command line handling patch has landed. Need to allow applications to more easily override command line options. bsmedberg has some ideas on this subject at XUL:Command Line Handling.
TODO -- Verify. Need to make sure Xremote and Win32 DDE works properly. By default, -remote should confine itself to talking to the same application type.
TODO Need to support application icons. Ben Goodger has some ideas on this one. There are really two parts to this task: (1) under platforms that support it, it should be easy to associate an icon with the launcher for a XUL app, and (2) we should support window icons located outside the chrome/icons/default/ directory.
TODO Need a fully app-independent toolkit. At the moment there are still a lot of places with #ifdef MOZ_PHOENIX or #if MOZ_THUNDERBIRD, which really hinders app development for other toolkit apps. There are also some files (see bug 250868, bug 250793 and bug 250867), which are essentially the same for all toolkit apps, but have to be carried in every app-package, making bug-fixing and maintenance a real nightmare.
TODO Make it so that zero setup is required for app developers that want to play with XUL. (Suggestion from nrm).
RESOLVED -- Now that chrome.rdf is gone, we no longer encode absolute file paths in the install directory, I think. This means that you just need to allow XULRunner to write to $HOME/.$VENDOR/$APPNAME/ and equivalent on other systems. But, the app directory itself should be easy to move around. Make it possible to run xulrunner + app from read only media (CD's). Would be great for demoing webapps with webservice support etc.