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.
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.
10 comments:
IMHO this JScript, CSS Firefox front-end is one of the weakest points of firefox - it should get back to native widget implementation.(IMHO again)
Firefox has always used native widgets, but was never written solely in C++ or Objective-C. What is it about web technologies that you don't like? Is it that you find C++/Objective-C a more familiar development environment?
Interesting post.
I still remember the times when you could use Chromebug for debugging and inspecting - and it was great...
How is this debugger linked to the Content JS debugger? do they share the same code?
What about other tools, like the inspector? I would actually love to see all these tools in a separate window (well, just like Chromebug) - like a full-featured developer box.
Is this Firefox only? Or is it possible for all XULRunner based products? (which in my opinion should be the goal)
What is the problem with debugging chrome window globals? after all a chrome window is just a content window with more privileges - at least so it seems from the outside.
Thanks for the answers and I am truly looking forward to the results. It will make developing FF much easier!!
Chrome debugger and content debugger are basically the same thing, just different code paths depending on what the user is trying to accomplish. The debugger server can be reused in all mozilla projects and I've heard of a few people looking into getting it to work for Thunderbird.
Long-term (or possibly mid-term) we will provide the ability to move all of the tools in a separate window or a separate tab. Watch out for blog posts from others in the team about our progress in that front.
There is no problem with debugging chrome window globals, it's just that we didn't have enough time in our hackathon last March to get it working. This is now fixed in our current set of patches.
I don't have much knowledge of the internals, so here are some (hopefully not too annoying) questions for you:
How many components does the debugger consist of, beside the debugger server?
Ideally all code (including GUI) should be shared between FF, Thunderbird and possibly any other XULRunner application. Which part of the debugger is currently FF-only code, which parts are in "toolkit"?
How is the debugger loaded into Firefox? Are its elements in browser.xul or are the DOM elements dynamically created via a js-module? In the latter case the whole process could be stream-lined so that the debugger could be easily attached to any xul-window (even outside of FF).
Sorry for all the questions, but it is a really interesting topic, especially to me as a XULRunner user :)
If you want to learn more about the debugger, I suggest you start here and follow the links: https://wiki.mozilla.org/Debugger_Architecture
The frontend, which resides in browser/devtools/debugger/, has some Firefox-specific bits, but nothing that couldn't be adapted to a different embedding, if one was determined to do so. In general though, unless you are in the developer tools market, I think that using Firefox to debug any other gecko-based application would make the most sense.
Thanks a lot, that is really valuable information. I will look into it.
Another question, that is somehow related. Are there plans to support chrome window inspecting from the inspector?
We are certainly planning to make all of our tools work against browser chrome. As a matter of fact, the page inspector can already inspect XUL files in chrome: URLs and display their style properties.
If I understand correctly it uses remote debugging protocol to connect to Firefox. What if I wanted to debug an extension on mobile? How do I change the host? It does not honor remote debugger settings.
Debugging mobile add-ons is not currently supported. You may want to CC yourself in this bug to monitor the progress on that front:
https://bugzilla.mozilla.org/show_bug.cgi?id=818382
Post a Comment