LinuxPipeline Interview – Firefox Extensions

Huh. I sent Howard Wen these “interview” questions on 29 September 2005, but didn’t see that the article had actually been published last month.

Amusing that he both starts and ends the article by basically quoting my response’s first paragraph…


1. What drew you personally to wanting to develop an extension for Firefox?

I’ve had slightly different motivations behind the various extensions I’ve created and contributed to, but the theme common to all of them is that I’ve seen ways in which my own browsing experience could be improved; if others find those changes worthwhile, that’s even better.

Adblock was the first extension I was involved with. I got my start there in May 2004 when the bleeding-edge nightly versions of Firefox were being made completely unusable by Adblock, which at that point was merely one of a dozen or so extensions I liked. After waiting a week or so for the head developer to release a fixed version, I dove right in and basically poked around Adblock’s source until it started working.

Some time back, I noticed that I’m really not very good at typing in URLs — I’ll often add a quote or a backslash to the end, or type “.rog” instead of “.org”, and hit Enter, and then I feel like an idiot for having made such a dumb mistake. But one day I thought to myself, “Hey, wouldn’t it be cool if Firefox could figure out what I *meant* to type and fix those stupid little mistakes for me?”, and whipped up a little extension that can do just that. I think that’s how many of the most popular extensions out there started: one person who actually uses Firefox every day saying to themselves “Wouldn’t it be cool if…”, and then going out and doing it.

2. How difficult (or easy?) would you say it is to develop for the browser? What kind of programming skills would you advise one must have?

Well, there’s really no limit how how complex an extension can be, but to create, test, and debug a very simple one “from scratch” might take a week or so. It’s probably important to note that extensions aren’t the only option for modifying Firefox: because the interface is built with easily-editable plain text files, simple new functionality and interface changes can be made without the need for a full-blown extension. Those sorts of changes can be done in less than an hour, once you know where to look (I contributed two how-to pieces to the O’Reilly book “Firefox Hacks” about this).

As for programming skills or experience… well, I don’t think you’d want to start off someone new to programming with an extension, simply because it’s a sort of sensory overload when you first look behind the curtain at what makes Firefox tick. That said, there aren’t many huge requirements for starting out with extensions. A solid understanding of HTML, since Firefox, and its extension’s interfaces, are built from a similar markup language called XUL. A little programming experience in almost any high-level language will translate very easily to JavaScript, the language Firefox uses for extensions.
Arguably, the biggest requirement is that you have to know how to use Google (and sites devoted to Mozilla coding). There are at least two complete and free online books about extending Mozilla, and loads of other tutorials covering all of the concepts and technologies relevant to extensions. Plus, when you first start out, almost all of the questions you’ll have and challenges you’ll face will have already been answered and solved by somebody somewhere, and your job will be much easier if you can find their solution rather than hacking out your own. Later on, as you explore the back-end XPCOM parts of the Mozilla platform, reference sites like xulplanet.com are absolutely invaluable.
Documentation for extension authors has traditionally been one of the areas in which the Mozilla platform has been weakest, but wikis like developer.mozilla.org and kb.mozillazine.org are, I think, a step in the right direction.

3. What technical issues/challenges did you have to deal with in developing your extension? Were any of them tied directly to the Firefox browser itself?

I’d say there are four primary “issues” that I ran into while developing Adblock, and which I think are generally applicable to extensions and even most software:

0. Goals.
What should the extension actually do, and what should it declare outside of its scope? What features are worth adding, and which aren’t?
1. Paradigms*.
This is where you figure out exactly what sort of building blocks you have to work with. For extensions, this involves understanding the technologies Mozilla makes available: XUL, XBL, RDF, JavaScript, the DOM, chrome, and XPCOM, to name a few.
2. Architecture.
Choosing building blocks and figuring out the most elegant and efficient way of combining them into a working application (or extension, as the case may be)? User-interface design is a part of this category.
3. Details.
I’ve heard that both God and the Devil hang out in this bar. For extensions, this encompasses everything from syntax errors, to bugs in the way the architecture was translated to code, to the usability of the interface.

*The really sticky bits about high-level technologies like RDF are in understanding the worldview implictly espoused by the technology. You cannot really use something effectively until you understand how its creator viewed the world, and the problems they wanted to solve. I’m terrible at analogies, but here’s a shot: Trying to use a hammer as a screwdriver might sorta kinda work, but its ineffectiveness is a reflection of a lack of understanding about the nature of hammers, how hammers were meant to be used. In the hammer-perspective, the world can be boiled down to nails that need to be inserted into wood — screws simply don’t enter into it. Likewise, RDF sees the world as a collection of objects, properties, and targets, or, even more abstractly, nodes and labelled arcs connecting them. It’s a bit of a mind-bender at first, but useful once you wrap your head around it.

4. What are your feelings about the fact that every major version of Firefox tends to “break” most extensions?

Oooh. Since most readers are likely to miss why you put “break” in quotes, I’ll fill in:

In August 2004, when many changes were being made to the extensions system in preparation for Firefox 1.0, and update.mozilla.org was just getting off the ground, one of the new features that was added was something called a “maxVersion arc”. Along with a “minVersion” arc, it was a way of allowing an extension to specify that, for a given target application (e.g. Firefox or Thunderbird or the Suite), it wouldn’t work before or after a certain version. If the user tries to install an extension with a Firefox maxVersion arc of 1.0 on Firefox 1.5, the installation won’t succeed, and if the browser is upgraded past the maxVersion arc of an already-installed extension, the extension is disabled. Now, this is useful if, for example, your extension makes use of a whiz-bang new feature in Firefox 2010 and would render the browser unusable in anything before that, or if Thunderbird pi makes your extension obsolete. The problem is that update.mozilla.org requires both “arcs” to be present, and will not host any extension that claims that it’ll work with a version of Firefox or Thunderbird that hasn’t yet been released. This has had the unfortunate but all-too-predictable effect of leaving a “dead zone” after major releases in which many extensions are not actually broken, but their authors haven’t had time to update their compatibility information and so Firefox disables/doesn’t install the extension until its author manually updates it, however long that might take. Usually it’s less than a week or two, but using Firefox without one’s favorite extensions, even for a week, can be a surprisingly painful experience.

Anyways, it’s just always struck me as a fundamentally broken system, and has been a “pet bug” of mine since day one. I argued fairly vigorously against it at the start, and I can’t think of a single extension developer speaking out in favor of it, but it was pretty clear from the beginning that those who had the power to change the situation didn’t really grasp that there was (or, originally, would be) a situation resulting from their idealistic policy. Last I checked, actually, the original advocates of this policy have moved on, either to different parts of the project or to other projects entirely; whether that will make the issue more or less likely to be fixed I don’t know. Those in control still seem firmly entrenched in their position that this situation is a Good Thing, so I’m not optimistic, but I sort of stopped caring long ago.

Really, the only positive note is that Ben Goodger had the insight to give developers, inadvertently or not, a not-too-difficult way of circumventing the whole mess, through online update.rdf files.

5. Do you have any suggestions or general comments about the way the Firefox developers have been handling extensions — their policy toward them?

Firefox’s developers have been very, very supportive of extensions. Ben Goodger, the lead developer of Firefox, is himself an extension author, both as part of his job at Google and independently. Asa Dotzler is one of the strongest advocators of extensions that I know of. The low-level Gecko hackers like Boris Zbarsky and Brendan Eich (creator of JavaScript) are quite good about answering technical questions extension developers might be having problems with. I think pretty much everyone involved with the Firefox project is well aware that extensions are a major factor in Firefox’s adoption: the “alpha geek”, cutting edge crowd appreciate the cool features that can be added to the browser, while more average users appreciate the features that can be taken out of the browser.

Ironically, I think that until this summer, the most extension-hostile part of Mozilla was update.mozilla.org. They were mismanaged, understaffed, way behind schedule… at one point, when extensions had to be manually added to the site by one of the administrator, with a lag time of at least two weeks, they completely stopped accepting new or updated extensions. Things are better now, but were ugly for a while.

6. “Extensions” verses “plug-ins” — do you think there is a technical difference, or is it more of a matter of semantics, a way of thinking?

Before I begin, let me piont out that this is merely the perspective of one extension developer who doesn’t claim to be any sort of expert on the technical details of plugins; these views are just what I’ve picked up in my time working on Adblock. That said:

There are technical differences, but I can see how it’d be confusing for somebody new to the Firefox scene. At the lowest API-level (that is, from the perspective of a programmer) they’re not very similar, but as you look at them more abstactly, or from a user’s perspective, they’re two sides of the same coin.

Generally speaking, extensions are a sort of “superset” of plugins. Extensions are a Mozilla-specific way of extending or modifying the behavior and interface of a Mozilla application, which is a very general goal indeed. Plugins, on the other hand, are a much older idea than extensions, and also aren’t Mozilla-specific. A plugin is usually designed to add a very specific sort of new functionality to the browser in which it’s integrated: displaying new types of content.

If you created a super-efficient new image or video format and wanted to have Firefox render those images or movies “inline” with other web-page content, instead of handing it off to a separate application to view, you’d write a plugin. When you view any kind of movie (QuickTime, Flash, WMV, whatever), it’s the plugin, not Firefox itself, that figures out out how to make it play. If, on the other hand, you wanted to, oh, re-architect the way bookmarks are handled, storing everything in an easily searchable database instead of the current HTML-like flat file, well, that’d be a job for an extension.

Plugins are, to my knowledge, always compiled, for performance reasons; extensions can be compiled but usually are not, for compatibility and ease of development.

Until recently, plugins and extensions had separate ways of being installed — plugins were usually (and maybe had to be, I don’t know offhand) installed by a separate executable, like with the Flash installer. Extensions, on the other hand, were packaged in .XPI files and installation would be installed by Firefox itself. With recent version of Firefox, the lines have gotten more blurred, since “third-party” installers can effectively install extensions, and plugins can be packaged and distributed as XPIs… Plus, as far as I know, there’s no technical limitation making it impossible to create an extension that can render new types of content — that is, create a plugin using Mozilla-specific XPCOM code instead of the “normal” way. Difficult, yes, worthwhile, no, but to my knowledge not impossible.

7. Finally, general information about you, in order to identify you properly in the article: Your occupation (or student status) and place of residence in the world.

I’m currently a freshman at the University of Delaware.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s