Shining Light on XUL Dark Matter

Wednesday, May 23rd, 2007

Late last year, roc wrote about XUL Dark Matter: semi-private intranet or domain-specific applications that are using XUL. Mark Finkle and I are setting out to try and get an estimate of the size and needs of this community, and how changes to XUL (especially in the Mozilla 2 timeframe) could help or hurt them.

Next month Mark will be in Tokyo and I will be in Paris for the week surrounding the Mozilla Developer Days. I am very interested in meeting up with developers of these semi-private XUL applications. If you are or know one of these developers, please encourage them to contact me so we can talk.

Here are some of the specific questions I’m trying to answer:

  • Why did you choose XUL?
  • Why was HTML insufficient for your needs?
  • If we added specific features of XUL to HTML, would you use HTML instead? e.g.:
    • Specific UI controls easily available
    • Templates
    • Overlays
    • Native Look and Feel
  • How do you control the version of Mozilla your users view your app with? Do you have concerns about the future stability of XUL?
  • Do you use XBL?

XULRunner: What we are doing

Tuesday, May 15th, 2007

In June 2003, Mozilla version 1.4 was released. For the first time, the Windows installers of Mozilla installed two separate pieces: the Gecko Runtime Environment (GRE) was installed into a shared location on the user’s hard drive, separate from the application components. Standalone installers for the shared GRE were made available so that other applications embedding Gecko could use the shared runtime. Life was full of promise… until users started upgrading or uninstalling their applications. The nightmare unfolded gradually: unsuspecting users would install a new version of Mozilla and Netscape or AIM would stop working. System administrators would install one version, and users would install into a different location, and both installs would fail to work correctly. It was not uncommon for the computer to become so horked that no combination of running uninstallers and installers would fix it: the only solution was to go into the registry and manually remove offending settings.

To this day, the phrase “GRE” conjures visions of frustrated users, unhappy developers, and unreliable instability.

The Perils of a Shared Runtime

This is the peril of a shared runtime, and one we absolutely must avoid. It is fiendishly difficult to get right, and the consequences of getting it wrong are devastating for users and developers alike. In March 2005, I posted a vision of how a shared XULRunner runtime could be implemented sanely. It kept registrations of installed runtimes and applications, and made sure that the correct version of the runtime was always available to applications. The XULRunner roadmap referenced this plan for XULRunner 1.9 and Firefox 3. Time has moved forward and we are now making hard decisions about features that were planned for Firefox 3, throwing many away because they do not fit in the schedule. The shared XULRunner runtime is one of those features.

This is the long story behind Mitchell’s post about XULRunner investment and Firefox 3. Mozilla is not “killing XULRunner”. It is merely stating the (obvious, I thought) fact that the previously published roadmaps are incorrect, and reiterating our support for continued development of the platform.

What are we doing?

Even though Mozilla isn’t going to ship Firefox 3 on a shared XULRunner, it is continuing active support of the Mozilla platform and the XULRunner project in particular:

  • Firefox 3 might ship a “private” XULRunner. A private XULRunner is a standard XULRunner build, but rather than trying to share it between Firefox and Thunderbird and other applications that might wish to use it, each application woulds ship and update its own copy independently. We have had a tinderbox building FF+XR experimental builds for months. The major tasks left to turn this on by default are mainly packaging issues to make it install correctly, and landing places-bookmarks. But Mozilla isn’t willing to let the Firefox 3 schedule slip for a feature such as XULRunner, so it may not make it in time. Developers who are interested in helping make this happen should contact me!
  • Make sure that prepackaged XULRunner builds are available.
    • If Firefox 3 ships on top of XULRunner, the build process will produce XULRunner packages “for free” without requiring the Mozilla release team to do separate release work.
    • Otherwise, I will be working with interested developers to make sure we have contributed XULRunner builds. This may take the form of build machines provided by Mozilla on the community network, or build contributed from elsewhere. The Eclipse AJAX Tools Framework community is already creating contributed builds of XULRunner 1.8.1.x; this is a natural continuation of that process.
  • Linux distributions will be shipping Firefox on XULRunner. Several Linux distributions are already shipping XULRunner packages by default, for use by Epiphany and other Mozilla embedders. These distributions have already indicated that they are planning on distributing a shared XULRunner package and building Firefox 3 on top of this package. This will reduce the maintenance burden of Mozilla security updates significantly.
  • Continue to support the XULRunner ecosystem. XULRunner is being used in a variety of new and exciting applications. Mark Finkle and I will continue to work with developers using XUL and XULRunner to uplift appropriate features and code back into the platform, as well as solicit, consolidate, and publish documentation. XULRunner is nothing more than two files which bootstrap an application and hook it up to the Mozilla toolkit: contributed patches help make life better for all Mozilla developers, including Firefox and its extension ecosystem. Perhaps something like MozPad would be helpful, though I would really like to get as much of that documentation back into the Mozilla Developer Center as possible, for shared consumption.
  • Continue development in Mozilla 2. Mozilla 2 will have a clean separation between the XULRunner platform and the applications built on top of it. Having a clean API separation and build system separation between components will reduce the barrier to entry of new hackers for both the platform and the applications built on top of it. Whether this means we will have a shared runtime, or simply have better tools for producing applications on “private” runtimes remains to be seen.

The Power of Openness

I would like to extend a special acknowledgment to Ben Turner of Songbird for his continued support and patching of XULRunner and of the Mozilla build system. He recently asked me “how can I help make the Mozilla build system easier to use for external applications?” This is the kind of question that makes me happy and lifts my spirits: there are some low-cost changes to our platform that could make everyone’s life a lot easier, and all you need is to send me an email or IRC ping. The XULRunner team is not “less that one developer”, but it is dozens of Mozilla Corp. employees, and hundreds or even thousands of developers working on the entire Mozilla platform. That I’m the only Mozilla Corporation employee working on nsXULStub.cpp is irrelevant, and a distraction from the accomplishments that we have all made together.

Unit-Testing Update

Tuesday, November 28th, 2006

Unit testing of the Mozilla toolkit has been making some great progress behind the scenes, as developers look at how their current bugs are going to be tested. I spent the morning looking through toolkit checkins since my original announcement, and only a couple bugs landed without proper testcases. I think we are ready to start the triage process for older bugs, and I so I have created a status page with bugzilla queries. If you are interested in volunteering, I would love help with triaging bugs that do and don’t need testcases (this is also a great way to learn about our codebase). The current stats are:

Needs triage


Needs testcase (in-testsuite?)






The stats aren’t really accurate, since most of the feed parser bugs are filed in the Firefox product, even though they are fixed (and tested!) in toolkit code.

New Toolkit Peers, and Focus

Monday, November 6th, 2006

I’d like to welcome Asaf Romano (mano) and Gavin Sharp as full toolkit peers: if you’re not up on the checkin rules, this means that they can review patches in any area of the toolkit. I’m excited that we have people available to replace inactive peers as time goes by and keep a healthy project.

Also, I posted on the Mozilla Developer News blog about a new unit-testing policy that I’m implementing for all new checkins to the toolkit. Please read!