# Firefox/CruiseControl Extension

I’ve been having some issues with my installation of Firefox for a while now (notably Javascript-based hyperlinks not working properly), so I decided to download the latest trunk version of Deer Park (Firefox 1.1), which is in alpha at the moment.

It’s early days for Deer Park, but from what I’ve seen so far, it will be excellent. It’s noticeably faster at starting up than Firefox is, for starters. And it now has built-in SVG support, which is a very useful addition – hopefully we can start publishing UML diagrams directly from our modeling tools as SVG straight onto a Wiki someday soon. For now, though, the SVG support still has a few flaws – it can’t seem to handle compressed SVG files, and it still only supports a subset of SVG 1.1. The JavaScript engine looks like it has been beefed up considerably as well. One of the most noticeable enhancements is the addition of native XML handling, via ECMAScript for XML. Oh, and I’ve also been using the Outlook 2003 Silver theme, which is very cool.

One small plugin I found recently (and which I had been idly wondering if one existed a couple of days beforehand) is the CruiseControl Firefox extension. This is a nifty little extension that queries a CruiseControl installation and displays the build status of your projects in the Firefox status bar. Quite neat – and a very small plugin (only about 5K, including images). The only problem is that it (like most other CC-related applications that I have seen) is just a simple screen-scraper that retrieves the build results page and parses the HTML, extracting the status and last build time of each project in the status list. We have customized our CruiseControl installation so much that it can’t find what it is looking for in the returned page anymore. So I decided to take a quick look at the plugin itself and try to fix it. It turned out to be much easier than I thought.

Writing a Firefox extension is actually very simple, and the CruiseControl extension is the perfect starting point if you want to learn how an extension is put together. I just downloaded the extension, unzipped the .XPI (which is just a zip file), and created a 10-line Ant build script to build the extension. The extension’s logic is contained in one single JavaScript file, and the quirky Mozilla XPCOM model is easy enough once you get used to it. For instance, here is how to log to the JavaScript console:

function ccLog(aMessage) { if (isCcDebug()) { var consoleService = Components.classes['@mozilla.org/consoleservice;1'].getService(Components.interfaces.nsIConsoleService); consoleService.logStringMessage("ccMonitor: "+aMessage); } }

Notice the naming syntax for the Mozilla interfaces.

This begs the obvious question – why doesnt CC have a Web Services API where you can query this kind of information programmatically? Firefox itself has a stable and mature Web Services API, and it would make writing these kind of applications a piece of cake.