Writing software, the wrong way

Wednesday, March 19, 2008

yay, incompetence

So I have started doing XPCShell tests as part of my next release. This has been giving me a lot of trouble, and not because tests are failing, but because my components and interfaces weren't being registered to XPCShell's liking (the component works fine in Firefox). Today I find, it was because of my incompetence.

When I exit XPCShell, I got the following message (XPCShell prints its error message when you quit on Windows, unless you call the quit() function).

JS Component Loader: ERROR file:///c:/builds/firefox-debug/mozilla/mozobj/dist/bin/modules/XPCOMUtils.jsm:115
TypeError: i is undefined


This is particularly tricky because it looks like its an XPCOMUtils.jsm error, when in fact it isn't. The mostly likely reason is that a component is trying to use an interface it cannot find, and therefore the component fails to register. But why can't it find it? I checked XPCShell and got the expected message :

js> print(Components.interfaces.nsIWindowsRegistryService)
undefined


After asking in #developers (twice) thinking that I need to add an EXPORT line to Makefile.in. Waldo pointed me to Javascript HTTP server code in netwerk/test/httpserver/Makefile.in. I compared Makefiles, and noticed one thing that may be causing my problem :

46 MODULE = test_necko

I kept everything under one module (grouppolicy). The tests being in the same module as the extension seemed like one rational reason why my code was working in Firefox but not in XPCShell, so I changed by module from grouppolicy to test_grouppolicy.

And holy **** did it work.

js> print(Components.interfaces.nsIWindowsRegistryService)
nsIWindowsRegistryService


I was a little disappointed that I had to spend two days on such a simple mistake. But I was happy enough that I stopped working to start this blog post. But it made me think about how little I know about what I'm doing sometimes, because we copy and paste a lot of things (Makefile.in, install.rdf). And naturally, when something goes wrong we don't know what to do. In fact, I don't know what a lot of lines in a typical Makefile.in do. But it is mistakes like these that help you learn.