The Future of Mozilla Application Development

by David Boswell and Brian King, coauthors of Creating Applications with Mozilla

In April, announced a major update to their development roadmap. Some of the changes in the new document represent a fundamental shift in the direction and goals of the Mozilla community. To help make sense of how these changes will affect Mozilla application developers, this article provides an analysis of the new roadmap and also demonstrates how to convert an existing XPFE-based application into an application that uses the new XUL toolkit. For the purposes of this article, the original Mozilla applications will be referred to as the Mozilla suite, and the new platform will be referred to as Mozilla Firebird.

Stand-Alone Applications

The biggest news in the roadmap update is that intends to stop development of the application suite it currently produces in favor of stand-alone applications. When Netscape created the Mozilla open source community, it released the code for their Communicator browser suite that included a web browser, mail and news client, HTML editor and an address book. Over the past five years the community has re-written the code base and has added many new features and other applications to the suite. The community itself has changed over this time and producing a single monolithic set of applications is no longer its main goal.

In place of the browser suite, development will focus on a stand-alone Mozilla Browser (based on the Mozilla Firebird project, formerly called project Phoenix) and a Mozilla Mail application (based on the Thunderbird project, formerly called project Minotaur). Both of these applications represent a second generation of Mozilla application development. For a short period, the first generation application suite will be worked on in parallel with these new applications but development will switch focus to Mozilla Browser and Mozilla Mail once it has been decided that the transition to the new projects has been completed.

The fate of the other applications in the suite is a little less certain. Development will continue on each, but there are questions about how they will be maintained and how they will be released once the browser suite has been divided up. MozillaZine recently ran a story on the future of one of the other applications from the browser suite, Composer, the HTML editing tool. Daniel Glazman, a Netscape developer, has offered to maintain the project going forward and to make it a stand-alone application so it can be run separate from the browser. Once that happens Composer will be just like other independent Mozilla development projects such as the Mozilla Amazon Browser or Xabyl, a visual XBL editor.

For end-users it will probably take some time to get used to these changes. Currently when a new version of Mozilla is released (for instance, the 1.3.1 release that came out on May 7) people who download it get a number of distinct applications that are tightly integrated with one another. In the future, the different applications that releases will have separate development schedules, will likely not be released at that same time and will not be integrated as closely as before. For users who think Mozilla is currently bloated with too many features and want just a browser, this is great news. Of course there will still be a rich set of extensions and add-ons for these applications that will allow you to customize them however you like.

XPFE and the New Toolkit

Developers who have been using Mozilla as a platform for creating their own XUL-based applications or add-ons will also have some changes to get used to. Although there will most likely be some pain in the transition, the changes in the roadmap represent positive steps that is taking to encourage Mozilla application development. The new roadmap is a strong endorsement of the concept of XUL and of Mozilla application development in general.

There is a possibility for confusion when you take a closer look at what exactly the roadmap is talking about changing. In the transition from Mozilla as an application suite to Mozilla as a platform for application development, the specific XUL-based toolkit that has been in use to date is being replaced with a new XUL-based toolkit taken from the Phoenix project. XUL itself is not being replaced though, just upgraded. The following quote from the roadmap clarifies this point:

Note: the Phoenix toolkit is a compatible reimplementation of the XPFE toolkit, with added features such as customizable toolbars. We are not starting a new C++ GUI toolkit, we are simply moving to the next generation XUL toolkit.

Previously the application framework side of Mozilla was seen as largely secondary to the original goal of creating an open source version of the Communicator browser suite. It's a testament to the developers in the Mozilla community that they were able to create a high quality, web-oriented, cross-platform application framework that a number of companies and many individual developers are already using without that having been their primary focus. Now that Mozilla as platform is becoming the new focus for the community, changes are inevitable but these should all be changes that ultimately make life easier for developers.

The rest of this article provides details about how the xFly application has been converted from the old toolkit to the new one. There is good news and there is bad news about the work involved in the transition from a Mozilla package to a Firebird extension. The good news is that the basic architecture of the application does not change -- XUL is still used in conjuction with other technologies such as JavaScript, CSS and XBL. The bad news is that there are some changes to be aware of -- there are minimal changes in XUL and XBL, but the biggest changes involve how things are packaged, registered and launched.

The xFly example application has been taken from the Creating Applications with Mozilla book that deals with Mozilla development using the original Mozilla browser suite. Another purpose of this article was to examine how relevant the book will remain when the new roadmap changes are fully in place. It is our opinion that other than the changes mentioned here, the book will still be a very useful resource for application and extension developers targeting the new Mozilla platform.

Packaging Your Extension

A package in this context refers to software that was installed on top of an existing Mozilla installation, and typically launched from that environment. Examples include the Google toolbar or Optimoz. As already mentioned, the changes to your XUL and XBL code should be minimal at the moment. However, the real fun begins when you want to register your application and integrate it with the Firebird platform. This section will cover the installation, the application settings, and the launch options available to your extension once it is installed.

To follow along with these examples, you will need to install the Firebird 0.6 release (available for Windows, Linux and Mac OS X) and the xFly extension. Once installed and launched you'll notice there's not much to the xFly application. It is currently suffering from bit-rot, but it still serves as a useful example for our discussion here.

Note: Keep in mind that the new roadmap just recently came out and that many of the changes that it discusses have not been made yet. This example should still give you a good idea about how you can go about converting your existing application or extension, but be aware that additional changes may come up as the toolkit continues to evolve.

Let's start at the end of the story, with the installation script, and work back from there. xFly is packaged and distributed as a JAR file, contained beside an installation script in the XPInstall file.

addFile("We're on our way ...", "xfly.jar", // jar source folder getFolder("chrome"), // target folder ""); // target subdir registerChrome(PACKAGE | DELAYED_CHROME, getFolder("chrome", "xfly.jar"), "content/"); registerChrome(SKIN | DELAYED_CHROME, getFolder("chrome", "xfly.jar"), "skin/"); registerChrome(LOCALE | DELAYED_CHROME, getFolder("chrome", "xfly.jar"), "locale/en-US/"); The code snippet above is taken from the install.js file, the full version of which can be found here. First of all the JAR file, xfly.jar, is added to the chrome folder, then the chrome folders contained within it are registered with the chrome registry. There is nothing new here, and therefore this script is backwards compatible with the Mozilla suite. This is important to remember, because if you have a will to do so, your extension will still work with the Mozilla suite as well as with Mozilla Firebird. Now let's examine some of the files contained in the chrome folders.

Registering with Mozilla Firebird

The first thing you will probably want is to add your application to the list of extensions in the Firebird Options (Tools->Options menu) window. All that is required for this is one line. In the extension manifest, the main contents.rdf file, add the following to the package description:


This tells Firebird to list the program in the list of extensions once it is registered. Here is the full description, which includes some other useful information such as the author, name, project URL, and a description of the extenstion which appears in the listing:

<!-- package information --> <RDF:Description about="urn:mozilla:package:xfly" chrome:displayName="xFly" chrome:author="Frillies" chrome:authorURL="" chrome:name="xfly" chrome:description="[2003-05-04] Adds xFly application for viewing examples contained in 'Creating Applications with Mozilla' []" chrome:extension="true" chrome:settingsURL="chrome://xfly/content/xflysettings.xul"> </RDF:Description>

xFly listed as a Firebird Extension
xFly listed as an extension in the Options window

Another new description property is chrome:settingsURL. This enables the 'Settings' button which opens a window, the definition is which is contained in the file pointed to by the property. For most applications, the contents.rdf file resides in the contents/ folder, or wherever you main XUL files are.

Launching Your Extension

There are many different ways that you can launch your application from within Mozilla Firebird. These include via a menu item, or a toolbar button. It is the latter of these two that is discussed here. The toolbars of Mozilla Firebird are highly customizable, much more so than in the Mozilla suite. You can add and remove buttons which represent application functionality via Drag&Drop, switch between text only/text and images/images only, and add new toolbars.

xFly D&D button
xFly D&D button on palette

There are several steps you have to take to get this working. The first thing to do is to create your buttons. Note that to be effective you need to create 2 different size buttons, 20x20px and 32x32px. Firebird is capable of having small and large button icons. Next up is to write the XUL for the button:

<toolbarpalette id="BrowserToolbarPalette"> <toolbarbutton class="toolbarbutton-1" id="xfly-button" label="&xflyButton.label;" oncommand="toxFly();" tooltiptext="&xflyButton.tooltip;" /> </toolbarpalette> The <toolbarbutton> is contained in a <toolbarpalette>, the id of which (BrowserToolbarPalette) corresponds to the palette that contains the Drag&Drop buttons for the toolbar. The original XUL for this palette lives in the file browser.xul, which is the main window for the Mozilla Firebird application

More modifications are needed to the main contents.rdf file, which as well as having the extension information, it contains the overlay information. More specifically, it contains information on chunks of XUL in files in your JAR file that you want to be added into some of the main Mozilla Firebird application files. So the following is added to the list of files to overlay:

<RDF:li resource="chrome://browser/content/browser.xul"/>

Then the list of files (in this case the toolbarbutton definition is contained in the file xflyextensionsoverlay.xul) is added to the sequence for this file. What is essentially being instructed is that this is the file that you will be overlaying (the file where the button will be going).

<!-- Firebird --> <RDF:Seq about="chrome://browser/content/browser.xul"> <RDF:li>chrome://xfly/content/xflyextensionsoverlay.xul</RDF:li> </RDF:Seq>

If you explore fully the mainifest file, you will notice a description is still left in to overlay the Mozilla suite. A menuitem definition is contained in xflymenuoverlay_moz.xul, which overlays tasksOverlay.xul -- the file that contains the original 'Tools' menu definition for Mozilla. Once again this illustrates that your extension can be backwards compatible with the Mozilla suite.

Finally, you need to get the styles right for your button, related to the appearance of the image you created. Here is some of the code for the large and small buttons contained in the overlay CSS file, xflyextensionsoverlay.css.

#xfly-button { list-style-image: url("chrome://xfly/skin/images/xflyButton32.png"); } ... toolbar[iconsize="small"] #xfly-button { list-style-image: url("chrome://xfly/skin/images/xflyButton20.png"); } You will fall at the last hurdle unless you register your stylesheet, similar to the registering of your overlay XUL file outlined previously, but this time in the skin contents.rdf file. <RDF:Seq about="urn:mozilla:stylesheets"> <RDF:li resource="chrome://browser/content/browser.xul"/> <RDF:li resource="chrome://global/content/customizeToolbar.xul"/> </RDF:Seq> <RDF:Seq about="chrome://global/content/customizeToolbar.xul"> <RDF:li>chrome://xfly/skin/xflyextensionsoverlay.css</RDF:li> </RDF:Seq> <RDF:Seq about="chrome://browser/content/browser.xul"> <RDF:li>chrome://xfly/skin/xflyextensionsoverlay.css</RDF:li> </RDF:Seq> This convinces the two Firebird application XUL files to recognise the stylesheet that contains the image properties and values for your images. Something that we experienced during our testing was the icon not appearing correctly on the palette, instead as a group of unrelated icons. It was resolved by deleting your Mozilla Firebird user profile, something that is recommended in the 0.6 release notes. Now everything should be in place, and you can grab your button and move onto one of your Firebird toolbars in the position that you wish.

xFly button on toolbar
xFly button on toolbar

Hopefully this article has clarified some of the issues raised in the new roadmap, and given you the information needed to create a new Mozilla Firebird extension, or convert you Mozilla package to one. While the new toolkit is by no means mature, the aspect concerning installation and registering provides a standard mechanism for developers to distribute their Mozilla applications and add-ons. If you are interested in learning more, the following links should be a good place to start doing more research.