RoboGeek

Mozilla Internals are MESSY

I don't think this will come as a surprise to those who work with Mozilla itself ... unfortunately it was a surprise to me:

Mozilla Internals are MESSY

I use Mozilla and FireFox all the time. Even on my Mac, where Safari is freely available and a pretty decent web browser. However, as a user I didn't ever have to dig under the covers.

The last 4 months I've been digging deep under the covers of the Mozilla source code. The purpose is to create an automation tool for testing the Java plugin in Mozilla. The design we had in mind meant understanding deep internals of how Mozilla keeps track of the GUI components, so that we could know where they are, and then use the Java AWT Robot class to interact with the components.

In most GUI toolkits there's a fairly simple way to work with the component tree. In Java the Container class provides a getChildren method that lets you easily traverse through all the Components instantiated in the application. In WIN32 you use EnumWindows and EnumChildren(?). In Motif/Xt there's a "get children" method of some kind, whose name has faded in the 10 years since I've programmed with Motif. So, I thought, there ought to be something simple like that in Mozilla.

Nope. Instead, and this took some digging to find out, the components are stored as an RDF data structure. Why RDF? HeckifIknow, maybe someone thought it would be cool. This is especially odd as the description of the Mozilla UI is done with XUL, but it has to be translated into RDF before the GUI toolkit can work with it. Uh? Why? HeckifIknow. That's just the way it is. Fortunately I eventually found a few methods that would let me traverse through the component tree, but it was bassackwardsly hard to discover this, and even then I cannot get all the components.

But, to find this all out, well, that meant becoming conversant with the Mozilla source code.

See, the problem is that the Mozilla source tree is millions of lines of code, written in several languages (at least, C, C++, javascript, CSS, XUL, XBL, and DTD) and all of it poorly documented. There's some documentation on http://mozilla.org/, but it is all in varying states of being out of date. Plus it is rather scanty considering the size of the source tree. Next, the internal documentation is itself rather sketchy.

One of the core concepts of Mozilla is XPCOM - cross-platform common object model (which is somehow XPCOM). It's pretty cool, sorta, and sorta derived from Microsoft's COM model. You have a language-independant programming interface language derived from CORBA's IDL. Any XPCOM object implements programming interfaces defined in IDL. XPCOM objects can be implemented in some of the several programming languages mentioned above. XPCOM has a concept of "interfaces" similar to Java, where a specific IDL file defines one XPCOM interface, any object can implement multiple of these interfaces, etc.

While "cool" it's also a nightmare. This is because javascript doesn't have those interface concepts integrated with the language. In Java you have "reflection" built right in and you can easily query to determine what an object does, but in Mozilla's javascript this is tough. Instead when you call an XPCOM method from javascript you have an unknown object, with very little way of determining what that object can or cannot do. You're left .. get this .. with having to look into the Mozilla source code, discovering the actual code you're calling, looking at the actual object it's putting together for you, and that way learning which interfaces the object might actually implement. And, since the source code is so huge and cumbersome, and undocumented, and convoluted, and obtuse, this is very hard.

The seamonkey web site helps a bit - this lets you run queries over the Mozilla source tree and find related source files. It doesn't work as well as it could, as it's rather klunky around getting to the file you want, and cross-referencing between files. It also only lets you search the HEAD of the Mozilla source tree, but what if you want to search relative to some release in the past?

What does this all mean? It means that there's a hugely steep learning curve before you can become effective in working with Mozilla.

Looking back on it, I'm not at all sure I'd want to keep working with Mozilla. My project is going to be continuing for some months longer, however. Still, I'm reluctant to do much with it because the source is such a pain to work with. Give me the niceties of Java any day over this. Oh, and I'm not at all surprised, now, after having worked with Mozilla, that Apple's Safari developers chose to use the KDE based web browser rather than the Mozilla web browser when they created Safari. I'm sure anything has got to look like a dream compared to Mozilla.