A few weeks ago I wrote about Contributing to Firefox on WinXP, and last night, my patch got committed to the trunk! Whenever the next Firefox point release comes out, millions of people will be using the simple for loop that I wrote. Here's how the process worked:

1. 11-30-2005: submitted patch and requested review
2. 12-04-2005: passed review
3. 12-14-2005: I politely asked around on #xul and #developers if there was anything else I was expected to do before the patch was committed. I was told to email the reviewer or make a comment on the bug. I opted to make a comment on the bug.
4. 12-14-2005: Gavin Sharp replied to my comment apologizing for the delay, and committed my patch.

So, except for the 10-day delay and slight confusion over my role, I'd say it went pretty smoothly. This experience certainly encourages me to make more contributions. I've been using Sunbird for calendar stuff, and have seen a few minor glitches in that, maybe I'll toss in a patch or two there next.

In the process of converting my remote XUL apps to use Firefox 1.5, I found a bug in <tree>. The column picker breaks when you've added things to Array.prototype. That took many hours to find, after removing and re-adding countless lines of XUL and javascript. It came down to some functions we were adding to Array.prototype in one of our libraries. When I commented those out, it worked just fine. I installed the Console² extension, which gives some better error reporting, and found the a javascript error occurring in a file called tree.xml. It was a mess of XBL, but the problem was apparent.

The problem is the usage of in. in is rather introspective, and will iterate over all the properties on the object, including user-added functions. My guess is the author of this code is used to the Python in keyword, which just iterates over the values in the object. I figure changing that to not use the in keyword should solve the problem:

To test this out, I went into my Firefox chrome directory (C:\Program Files\Mozilla Firefox\chrome for me), unpacked toolkit.jar, and made that change in chrome\toolkit\content\global\bindings\tree.xml. Console² let me know where to look. In order to get Firefox to read my files, I had to edit chrome\toolkit.manifest to look in the unpacked directory instead of the jar.

Now that Firefox is looking at the unpacked source with the updated tree.xml, I restarted Firefox and saw that it worked. The next step was to file a bug, and submit a patch.

As this was the first time I filed a bug at Bugzilla, I did it wrong. Asking around on #js, Hannibal kindly told me to make a diff from CVS, and request a review. I had to install cygwin, and partially followed Jeff's instructions for setting up an MSVC toolkit Firefox/Thunderbird build environment. I wasn't concerned with needing to actually build it, so I only followed the bits about cygwin. After getting a bash shell working, I followed the Mozilla Source Code via CVS instructions, and got the source on my machine. The build failed, but I didn't need it to build me anything, I just needed all the source.

Once I had the source, it was all very easy, following the Mozilla Source Code via CVS verbatim. After some browsing, I found a policy page for Toolkit patches, the Tookit Review Requirements. From there I uploaded my patch to my bug, and requested review. Within an hour or so, my request had been bumped to another toolkit dev, (the original guy is on vacation), and my bug's status had gone from UNCONFIRMED to NEW, and its looking to be put in the mozilla1.9alpha1 milestone.

So, it looks like I might get a very trivial piece of code into Firefox, and have learned a lot more about how Mozilla's internals work, and how open source development works. If I get ambitious, I might get the source for other Mozilla projects and see if I can contribute to those.

I've now gotten permission to use XUL for another client, and this time around, I'm trying it a little differently.

Rather than serving up a .xul file, and doing everything with overlays, DOM manipulation, and XBL, I'm serving up a .aspx file, setting its content-type to application/vnd.mozilla.xul+xml, and then using ASP.NET to render XUL instead of HTML. Jeb (do you have a link, Jeb?) said he was creating XUL apps this way using JSP, so I figured I'd give it a try. So far I like it. This method lets me lean on my ASP.NET skills while I build up the XUL skills.

How I have it set up:

• One .aspx page per XUL layout, using <html:a> tags to navigate between them.
• One ASP.NET user control is on each page, ensuring all XUL layouts have the same template and include the same javascript and css files. I had tried do this with overlays, but didn't have much luck.
• A few IHttpHandlers to send RDF to my XUL, and JSON to my javascript.
• A few webservices that get called by my javascript, and the work is done in C#.

For now, I'm only using this on applications that require windows authentication to access the site, so to access the web services you'll need to be logged in. Security is still a concern, though, and eventually I'll have to expose some of these web services to wild. I've been considering some token system where the server passes a token to the client when it renders the xul aspx page, and then the javascript passes that token to the web services, but I haven't fleshed anything out yet.

I've been doing XUL work in XEmacs, and it has been pissing me off that xml-mode wasn't doing indenting or syntax highlighting automatically. I finally asked Nathan about it, and we figured out this addition to my init.el to make working with XML and XUL files indent nicer:

;;make xul files start in xml mode
(setq auto-mode-alist
		(append '(("\.xul$" . xml-mode)) auto-mode-alist))

;;make xml-mode indent
(add-hook 'xml-mode-hook
			 (lambda ()
				(setq sgml-indent-data 'T)))

I'm pretty confident no one but me uses the taskpool app, but just in case, I just made a pretty major update. In the last version, the tasks would get serialized to disk (in rdf:local-store) when you closed the program. Seeing as I leave my workstation on all the time, I rarely had the need to close the program.

Today windows decided I had done one "ctrl-shift-b" too many and spontaneously rebooted, losing all the tasks I had built up over the previous weeks of stability. I spent some time tonight refactoring the code and making things save automagically, so now not even killing the xulrunner process loses my precious, precious data. I also found some bugs where the rdf was getting corrupted, so that is fixed as well.

Downloads:

• taskPoolBundled.zip (5685 KB)
  To run, unzip the file whereever you want, and run the "taskPool.bat".
• taskPool.zip (55 KB)
  To run, unzip the file whereever you want, and run the "taskPool.bat". You must have downloaded XulRunner, and have xulrunner.exe in your path.

I've mentioned a little while back that I was working on a XULRunner app to keep track of my time, and I finally packaged it up for people to use. It's pretty basic, allowing you to add tasks to a list, and click on the task to start a timer. I end up adding a handful of tasks to the list, then clicking between them as people call or I receive emails, then every couple of days I punch the numbers into my billing system.

There are two distributions, one with the actual Win32 XULRunner app included, and one without.

• taskPoolBundled.zip (5635 KB)
  To run, unzip the file whereever you want, and run the "taskPool.bat".
• taskPool.zip (5 KB)
  To run, unzip the file whereever you want, and run the "taskPool.bat". You must have downloaded XulRunner, and have xulrunner.exe in your path.

var uhoh = new Boolean('false');

if(uhoh) 
   alert('Aww, no...');