JavaScript debugging updates

There have been a lot of interesting developments in the JavaScript debugging front since my last update, so let me give you a brief overview of the most important changes.

Let's begin with the eagerly awaited Firefox OS. Starting the debugger in Firefox OS has gotten way easier. There is a toggle in the settings app that will set or reset the devtools.debugger.remote-enabled pref, so that you don't have to mess with files and adb at all. At least for production builds that have marionette disabled by default. Developer builds will have to keep disabling marionette for a bit longer. You can find the Remote Debugging toggle in Settings -> Device Information -> More Information -> Developer. Note that you will have to reboot the device (or restart the b2g process) for the change to have effect. Also, as you can see in the screenshot, it's a good idea to disable out-of-process support while debugging, at least until the debugger can support it.

Firefox OS settings

While we are on the subject of debugging JavaScript on mobile, I shouldn't neglect to mention that Mihai Sucan has landed web console support for Firefox OS and Firefox for Android. There are still a few rough edges, particularly in the case of Firefox OS, but now you can connect your desktop Firefox to your mobile device and see the errors and logged messages, as well as evaluate JS code in the context of the mobile page.

Speaking of desktop Firefox, the amazing Victor Porof has landed an obscene number of patches in the last few weeks, with many fixes and tweaks for the debugger frontend. Of those I'd like to highlight the new functionality to search for variables in the current scope chain while the debugger is paused. Prepend your search with a star to search in the variables view. When you deal with large objects with long scope chains, finding the variable you are looking for can be like searching for a needle in a haystack. Now it's a piece of cake.

Searching for variables

And last, but certainly not least, chrome debugging support has appeared in Nightly this past weekend! This will make debugging add-ons or Firefox itself way easier than ever before. You will need to enable remote debuging (devtools.debugger.remote-enabled) and browser chrome debugging as well (devtools.chrome.enabled, the same pref you switch to get Scratchpad to run against chrome).

Chrome debugging preferences

This will get you a nice new Browser Debugger menu item in the Web Developer menu, which launches a separate debugger process to inspect your browser instance.

Browser Debugger menu item

There has never been a better time to dive into Firefox internals and become a valued contributor. Take a look at this bug, to see how simple debugging has just become. Help us make the web better, by improving the lives of more than 400 million users!

Debugging Firefox OS

A few months ago, long before the Firefox debugger had shipped, I had tried to see what it would take to get it to debug B2G, or as we call it now, Firefox OS. The hack proved successful and with time it grew into an important debugging target for us. I demoed it at JSConf last April, but at that time a lot of the debugger frontend functionality had not been available in nightlies. As of yesterday, however, nightly builds of Firefox can debug nightly builds of Firefox OS, both in the device and desktop versions. Let me give you a quick rundown of the necessary steps.

First of all you need to go to about:config on your desktop Firefox and turn devtools.debugger.remote-enabled to true. After restarting Firefox you will have a new Remote Debugger menu item in your Web Developer menu.

You need to change the same setting in Firefox OS as well, and that requires finding the prefs.js file. For desktop builds, this will be in gaia-repository/profile/prefs.js. For devices, you should connect it to the desktop through a USB cable, use adb shell to connect to the device, and find the name of the default profile in /data/b2g/mozilla/. The prefs.js file wil be in that subdirectory, which in my case is /data/b2g/mozilla/ngsweij3.default/prefs.js. You can get that file off the device using:

adb pull /data/b2g/mozilla/ngsweij3.default/prefs.js prefs.js
 
That will store a copy of that file in your current working directory. You need to modify this file and then send it back to the device with:

adb push prefs.js /data/b2g/mozilla/ngsweij3.default/prefs.js

The necessary changes to that file are the following two lines:

user_pref("devtools.debugger.remote-enabled", true);
user_pref("marionette.defaultPrefs.enabled", false);

They enable the debugger server and at the same time disable the Marionette server, to avoid a conflict that we haven’t resolved yet.

That is all that is necessary for the desktop Firefox OS case, but you need to do one more thing for debugging Firefox OS on the device. If you are going to debug over a USB connection (which will also provide helpful console logs via adb logcat) you will need to forward a local port to the device using adb:

adb forward tcp:6000 tcp:6000

Port number 6000 is the default and if you need to change it for some reason, you can do so with the following pref:

user_pref("devtools.debugger.remote-port", 7000);

Debugging over WiFi is also possible, although disabled by default, so you will need to change the following pref to do so:

user_pref("devtools.debugger.force-local", false);

In that case, you don’t have to do the port forwarding step, but you may change the port number in the same way.

In order for the new settings to take effect in the device you have to restart it with ‘adb reboot’.

That’s all folks! Now you just start your nightly Firefox and select the Remote Debugger menu item. A dialog will pop up asking for the remote address and port number to connect to. The defaults will work for the desktop Firefox OS or the device debugging-over-USB cases (unless you changed the port number of course!). If you opted for debugging over WiFi, you will need to provide the IP address of the device. You can find it by tapping on the connection name in the settings.

After the connection is established, you will see a list of the sources loaded on the device, giving you the option to inspect the code, set breakpoints, step through the execution or even modify the values of variables. Here is a screencast that shows the debugger in action:

A better introductory guide to debugging Firefox OS will be available soon on MDN. This is just the first step in supporting Firefox OS development with Firefox developer tools. Just around the corner are web console support and profiling, with more to follow in the near future. If you have issues or suggestions for these tools, please get in touch! Post a comment, file a bug or pop in #devtools for a chat. Let's make the web the best platform to develop on!

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.

JSConf 2012

This week I had the opportunity to attend JSConf. I've been trying to make it to one of these conferences in the past without success and I now realize I was missing a lot! Chris and Laura Williams deserve special credit for the excellent job they are doing here. Even though I missed all the parties (because jetlag), the venue, the speakers, the tracks, and the conversations were all top class. Highly recommended.

If I had to pick the highlights of the conference, an undoubtedly difficult undertaking due to the sheer number of awesome talks, my personal favorites would be these two:

The B2G phones given out by Mozilla to all attendees, a gesture that sparked the creativity of quite a few people, culminating in a few B2G apps after a few hours of hacking. Yes, it's that easy.

The chance to meet and listen to Dan Ingalls, in my humble opinion one of the greatest programmers of our time, giving his inspirational talk on the Lively Kernel. It would be a failure of our profession if the ideas in Lively Kernel do not find a way to reach mass market at some point. This system, like its predecessors Squeak and Dynabook, represent a more humane way of programming computers that could be a game changer.

My own Debugging B2G talk was well-attended, even though a malfunctioning video cable threatened to kill it before it even began. I received lots of comments afterwards and requests for access to the debugger build that I demoed, and even though I pointed people to the patches, I think that the best thing to do for those interested is to wait a few more weeks, until we get all of that work in nightlies. After getting back at the hotel I recorded a screencast of the talk for those who couldn't attend, but unfortunately you will miss me mumbling while frantically plugging and unplugging a video cable and cursing at thunderbolt ports. Hands down the highlight of the talk.




All in all it was a great opportunity to meat people, have conversations on the present and future of Firefox developer tools and ride a bull. Too bad I missed that last one.

Debugging mobile phones

Last week I posted an update on the progress we are making towards a functional JavaScript debugger in Firefox. We still have a ways to go before we get there, but the foundation this is based on, namely the Remote Debugging Protocol, provides a solid basis for debugging mobile browsers, and as it turns out, even mobile operating systems. Supporting these use cases is still farther down our list, but I decided to spend a few hours the other day trying to estimate how far we are from this goal. It turns out we are not that far, and I have a screencast to prove it.

I had done some prototyping work for Firefox for Android a while back, which was rather straightforward, so I was curious to know what would it take to tackle a more ambitious project: debugging Boot to Gecko. After a few hours of hacking and orienting myself around the B2G and Gaia code base, I got this far:



Not too bad I think for a few hours work. Don't expect this to be ready of course, before we have a working debugger in desktop Firefox. If, however, you'd like to follow along and maybe even lend a hand, you are always welcome!

Debugging JavaScript

tl;dr: Firefox nightlies now ship with an experimental JavaScript debugger. It's not ready for end-users yet, but we are feverishly working on filling in the missing bits.

Debugging is always hard, especially when debugging other people's code. Adding a bunch of console.log() statements, becomes tedious after a while and that's assuming that you are familiar enough with the code in question to know where to place them. Tools like Firebug are a tremendous help in this case. Having the ability to pause the execution at any point or inspect variables and stack frames, provides valuable insights into the runtime behavior of a program.

Firebug depends on the traditional JSD API in SpiderMonkey to perform its magic, but nowadays JSD is limiting in a number of ways. In order to overcome these limitations, the new JSDBG2 API was designed and implemented by Jim Blandy and Jason Orendorff, and the first version of this work landed in Firefox 8. Jim, being the kind of guy that has forgotten more about debuggers than I will ever know, designed a remote debugging protocol to separate the debugger from the browser, allowing for debugging desktop browsers, mobile browsers, mail readers and even more exotic software in the future. Dave Camp got a great protocol implementation up and running, but was assigned managerial duties (poor sap!) before having a chance to finish the job, so Victor Porof, Mihai Șucan and yours truly lined up to carry the torch. The culmination of this work landed in mozilla-central last week, including the remote protocol implementation and a prototype UI (disabled by default). It is now available in nightlies for adventurous souls to play with.

Let me be clear about that last point: what's in there right now is not useful for day-to-day work, even for experienced developers. There is no UI to add breakpoints besides the experimental Graphical Command Line Interface (whose awesomeness deserves a separate post), no stepping, no variable inspection besides call parameters and 'this', and numerous other limitations. In short: it's not ready, yet. In the course of the next weeks we will be furiously working to add the missing bits and improve the UI, so that it becomes a worthy addition to our existing suite of developer tools.

If, however, you are the kind of person who doesn't take no for an answer, here is what you need to do to play with it: type about:config in the awesomebar and set the preference devtools.debugger.enabled to true. Also, set devtools.gcli.enable to true in order to be able to set breakpoints. Restart your browser and select Tools -> Web Developer -> Script Debugger to open it. You will need to reload the page for the debugger to become aware of the scripts in the page (see? It's not ready!). Browse through the source scripts to find a place where you would like to add a breakpoint, then open the web console and type break add line <url> <line>. Don't worry about memorizing it, GCLI will guide you along the way, suggesting among the available options at each step. When the code hits the breakpoint, the debugger will display the stack frames and the variables in scope (not all of them, it's not ready, remember?) for inspection.

If you have better things to do with your time than play with experimental, uninished debuggers, but would still like to take a peek into what's in store already, here is a short screencast that should give you a broad idea. Note that the stepping functionality in the demo is not in the nightlies yet, because, you guessed it, it's not quite ready.



Ready or not, we would love to have any feedback you might have. Drop by #devtools for a chat, or file bugs to torturehelp us get things fixed. Rest assured, when it's done, debugging web apps will never be the same again.