XULRunner

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 .

Profiles

An application running on top of the XULRunner should have a fully managed profile directory. ("Managed" meaning that each app built on top of XULRunner should have its own vendor/appname directory for storing profile information.)

An application developer should not have to think too hard about profile details! What about sharing profile data (f.e., installed certs between xulrunnerized firefox/tbird)? Not an uncommon request.

What's in XULRunner?

XULRunner should basically be Firefox without everything under the browser/ directory. That means that it includes all the core "new" toolkit stuff that Firefox and Thunderbird currently share, including the extension manager. What is finally included in XULRunner is of course entirely up for debate ;-)

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

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

What needs to be done?

• RESOLVED. 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. Moreover, this problem has been completely eliminated IMO by bsmedberg's patch for bug 278534. That patch makes it so that XUL app authors never need to write resource://app/ :-)
• 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/.
• 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.
• 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.
• Need to allow applications to more easily override command line options. bsmedberg has some ideas on this subject at XUL:Command Line Handling.
• Need to make sure Xremote and Win32 DDE works properly. By default, -remote should confine itself to talking to the same application type.
• 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.
• 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.
• Make it so that zero setup is required for app developers that want to play with XUL. (Suggestion from nrm).
• Make it possible to run xulrunner + app from read only media (CD's). Would be great for demoing webapps with webservice support etc.
Other stuff...