Debugging Firefox

Last week we had a Firefox Developer Tools team get-together at the Mozilla London office. These meetups are an extremely valuable tool for the project to tackle hard problems, because when you put all of the experts on a particular hard problem in the same room, hard problems tend to run away screaming.

We managed to attack a lot of hard problems this week: a profiler, source maps, the developer toolbox, web console remoting and chrome debugging, were just a few of them. And not only that, but we also landed a few exciting new features as well, with fullscreen scratchpad and markup panel preview being my personal favorites. I'm sure others will cover the rest in appropriate detail, but I'd like to say a few things about chrome debugging.

Last March, during the previous team meetup we had managed to get a chrome debugging proof-of-concept working. We were thrilled by it, even though it was a big hack, because the implications were enormous. Something that not many people know is that the Firefox frontend is built in JavaScript, CSS and XUL, which is an HTML derivative with additional capabilities. That is, we use the exact same technologies that power your favorite web applications, to build the browser that displays said web apps to the user. This similarity has always been front and center to our thinking when considering tools for web developers: how can we use these tools to make hacking on Firefox easier?

Without easy to use tools, fixing bugs is time-consuming and adding features demands a very disciplined approach to programming. It hampers our ability to move the project faster and innovate rapidly. Furthermore, having a non-profit foundation to back the development of an open-source browser means that you don't have the option to simply throw more money at the problem, hiring more engineers than everybody else to increase the pace of innovation in the product. This is a browser created by thousands of contributors to take care of their own interests. We have to make their work easier, by giving them the tools they need to work faster.

When we did the chrome debugging prototype last March, the Firefox Debugger had been in trunk for a short while, disabled by default. No visual styling had been done on it and only the most basic of functionality was there. Six months later we have shipped the first version and we keep iterating on it.

The proof-of-concept couldn't debug chrome window globals, only modules, and was hijacking the remote debugging protocol in a hackish way that was guaranteed never to make it into a Firefox release. This time we have both kinds of globals supported and a sound protocol design that was agreed upon a few months ago.

This new tool, which we dubbed "Browser Debugger", will be useful to add-on developers, too. In my demo last week I used it to debug Firebug. We have patches under review or close enough that implement a first draft of the experience we aim to present users with. I want to land that as soon as we can, enable the feature by default (but conditioned on the devtools.chrome.enabled pref like other tools) and keep iterating.

It was without a doubt a very rewarding week. Some might expect us to also treat these rare events as opportunities to hang out, get drunk and take embarrassing pictures of each other. I am not going to either confirm or deny such allegations. At least not until I'm presented with hard, photographic evidence. Preferably on Flickr.