Burning Chrome

Of course, something will fall through the cracks...

Like any other major software project, Firefox 1.5 has bugs. It's a sad, unavoidable fact of life. And because I'm a bit cheap, I use Microsoft's free command-line compiler. Unfortunately, Firefox 1.5 in a pure state won't compile with it.

Thanks to Mook via #developers for pointing out to me bug 241528. Unfortunately, it didn't get approval for the 1.8 branch. Even if it had been requested once the patch received r+sr, though, there probably wouldn't have been enough time. RC3 (which became Firefox 1.5) was spun from the 1.8 branch just four days after the patch was checked into trunk. With the extended, absolute-zero freeze in place, it was pretty unlikely to get approval and land on branch, even if someone had tried. Too bad no one thought to request a blocking flag a few months ago.

I'm actually not upset about this, and I don't want anyone out there to be. I'm writing this blog entry for information. It's my own fault I used a compiler that isn't tier 1, and is pretty much unsupported. It's also my fault for never compiling Firefox on this machine before. I'm disappointed, sure, but I'm pragmatic. So the product didn't compile without an extra patch. The patch was readily available, I was pointed to said patch in ten minutes, and it applied cleanly. In open-source, you can't ask for much better than that.

This blog is just for your information, ladies and gentlemen who are also cheap BOFH's and PFY's. If you're using the free Microsoft compiler (2003 series) on a Mozilla Firefox 1.5 tree, watch for this patch.

That is all.

For all the people who busted their butts on Mozilla Firefox 1.5, thank you. This isn't your fault; it's nobody's fault. Sorry to rain on your parade with a little compiler failure. Firefox is guarding the henhouse just fine.

Where are the good chrome dev examples?

I spent a big part of today trying to fix a bug in xpistubs, with regard to flat chrome. I went through the XPInstall API docs for hours today, trying to figure out what the hell I was doing wrong. Hours. The code examples are sparse. It's not clear to the untrained eye which arguments refer to content inside a XPI (or JAR), and which arguments refer to the target applications. A few visual examples would have saved me a lot of trouble. Example:

Suppose this is the contents of your XPI file:

content
- foo.xul

This is the contents of your target chrome directory:

chrome
- browser.jar

To copy and register the content directory into chrome/content/foo, use the following:

Install.setPackageFolder(Install.getFolder("Chrome"));
var targetDir = Install.getFolder("Chrome", "foo");
File.dirCreate(targetDir);

addDirectory(null,        "content",      targetDir, "content/");
registerChrome(CONTENT | DELAYED_CHROME, targetDir, "content/")

Note the second argument does not have a trailing slash, but the fourth argument does.

I've never seen anything like this level of detail in any XPI guide, not even "Creating Applications With Mozilla". This sort of example is short, very self-contained (you don't need to read prior chapters), and can be inserted into the addDirectory API documentation without any trouble. (Even then, it's not entirely a good example. Which "content" argument is which?)

There's another reason I wrote the example above as I did. It's not jarred chrome, it's flat. Flat chrome is useful. Flat chrome means you can edit the files raw in your objdir, and when you're done, you just copy the files into your source dir. No dealing with jars at all.

Jar files are great for finished products. But when you're doing dev work, you want to play with flat chrome. Ideally, you want to keep all your files isolated so that things are relatively obvious. If you can build jar, you can build flat, and vice versa. Mozilla reacts happily to both.

We have a serious lack of good chrome examples, flat and jarred. Oh, I could dig through the archives of mozilla.org and eventually find a bunch of XPI packages. But it's not clear to me as a developer what's inside these things, and what makes them tick. These tests would be a lot more useful if there was a guide to them. "This is what that XPI is supposed to do. This is what each XPI has inside it. This is what the install.js file looks like. This is what each line does."

Every time I try to start a new project, I go through this hassle. Every time I start playing with XPInstall, I go through this hassle. It's insane. I know I could (and probably should, given how frustrated I am) write a nice bunch of addendums to current XPInstall docs. Is that what will solve the problem? Or can I wake someone up and say, "Have you ever tried to use these docs to actually do something?"

Bubble Bobble! In real life!

Now we just need some dragons.

Thanks again to Slashdot for the link.