I knew the day was going to be bad when I started commenting out JavaScript assertions in my own code. I just didn’t know how bad. The extended entry has all the gossip.

First off, I’m playing in Verbosio with attribute nodes, XUL text boxes, XUL menu items, and the DOM user data interfaces. New stuff, good stuff… except the attribute node that I got back from the user data entries didn’t match the node I was trying to match. Equal, but not the same, inside a DOMNodeRemoved event listener — which I thought was pretty strange.

Since they were equal, I thought, “Oh, just use isEqualNode() instead of isSameNode().” In other words, fake it. Bad practice, but this is 0.1, not 1.0, right? I’d implemented isEqualNode earlier this year, so why not? That made deleting the attribute work, and undoing the deletion worked too. But redoing the deletion didn’t work, because the attribute value from user data is null for some reason.

Several dump statements (and probably two hours) later, I’m no closer to figuring out the cause than when I started. I need Venkman. But I’m sick and tired of patching my code to make Venkman work. Instead, I thought, just grab a snapshot of Venkman and hack it into the Verbosio build process.

That didn’t work. It was always phoning home to addons.mozilla.org, and every time it did, addons said, “We don’t support Verbosio. Go away.” To which Verbosio responded by disabling Venkman. Try as I might, I couldn’t make it work. I thought about forcibly inserting an update.rdf reference into Venkman’s install.rdf (that would’ve solved the problem, but was too dirty a thing to do).

Next I tried to figure out just how XULRunner was talking to addons and override it. I thought, “Well, this is Verbosio. Of course addons.mozilla.org won’t support Verbosio. Verbosio’s not a mozilla.org product. So I’ll just run my own mini-update service from the Verbosio website.” I discovered there’s a preference, extensions.update.url which refers to the addons website. I replaced it with a custom update.rdf location. No good; it’s still pointing to amo. This didn’t make any sense. Finally I dove into the C++ debugger and found out the preference service ignored the preference completely and relied on a extensions.properties
file in a localization. This file, which had easily over 100 properties in it, included the one property I cared about. I could replace that file too, but it seems like a whole lot of bloat for one little damn detail. Why a localization file has stuff that can’t be localized is beyond me…

At this point, I’m pretty steamed from having battled it almost the entire day and making no progress on Verbosio. The best fix really is to make Venkman not depend on any one XULRunner application, but installable for all of them, as an extension to XULRunner’s toolkit. Unfortunately, our extension manager code can’t do this (bug 299716). It can support one product – whatever the application.ini says for the ID – and that’s it. Even if it’s based on another product – say, XULRunner toolkit – you’re out of luck.

Bug 299716 looks like a bug that, while important, has been shelved by the primary developers in favor of other, higher-importance bugs

. I can’t fault the community or the developers watching the bug for that. At the same time, if I need Venkman in Verbosio “the right way”, this bug must be fixed immediately. I can’t do anything more than request the bug block Gecko 1.9 in order to convince others to work on it. I am reluctantly forced to concede that the only way this bug will get fixed in a timely manner is if I write at least a first-round fix.

I really hate diving into unfamiliar code. Even if it’s in a language I know very, very well (like JavaScript). Ultimately, though, it’s the best of a bad set of options. My frustrations with not being able to easily apply Venkman, Inspector, etc. to Verbosio without repetitive work or scripting by shell or Perl have reached a boiling point, where I just can’t take it anymore. The bug would still be there if I hacked around my problems and forced things to work, and I’d just bump into the problem again for some other project (like XUL Widgets, JSLib, which I’ve already done some evil hacking for in Verbosio). Sooner or later, the hacks have to stop and good code fixing the core problem must be written. Now is that time, at least for this bug, and I dare not wait for someone else.

I’m going to work on the bug, but I won’t assign it to myself until and unless I generate a patch. Worst-case scenario, I don’t get anywhere. But I doubt that; I think I’ll make some progress and post at least a partial patch. Very likely, because I’m so blocked, I’m going to post a complete patch and get reviews.

Needless to say, Verbosio development has been shelved. Again. That makes me madder than anything else: that there’s quite literally nothing I can do until I fix a couple bugs that are critical to me, and merely irritating to almost everyone else.