The Thunderbird (Remote) Debugger is alive!

For quite some time now, I have been forced to use printf-style debugging for any work on the Mozilla Calendar Project. In most cases, its a real pain. Evaluating variables without restarting is so much more comfortable. There used to be Venkman, but due to ongoing “improvements” in the Mozilla Platform and Firefox, Venkman is broken and is no longer doing the job. When support for the first version of the Javascript Debugger interface (JSD1) is removed, that will be the final nail in the coffin of Venkman.

So it looks like we need an alternative. I’ve heard of lots of interest in creating alternatives, but the deal breaker is often the lack of time to actually work on a such project. In the meanwhile, Mozilla is investing time and resources to add native developer tools to Firefox. Maybe there is some way we can make use of these resources? Yes there is! The developer tools team is doing a great job. And by great I mean outstanding. Thanks to Firefox for Android and Firefox OS, the team designed the debugger in a client-server constellation. The Mozilla Platform provides debugger server component that is (almost) free of Firefox-specific code. Then there is the very Firefox specific developer tools client you know from the Firefox Tools Menu.

It became obvious to me that using this debugger server in Thunderbird would be a very future safe method. In contrast to copying the debugger UI into its own extension and make that compatible with Thunderbird, we just need to ensure that the already very general debugger server is kept clean of hardcoded Firefox-isms. For this reason I have applied to the Google Summer of Code as a student to make it happen.

Although the Summer has just started, I am proud to present a first success. With the latest nightly builds of Thunderbird 24.0a1 and a matching Firefox 24.0a1 nightly, its possible to debug Thunderbird code right from in your browser. Here is how:

  1. Download a Firefox nightly build.
  2. Download a Thunderbird nightly build.
  3. Start Thunderbird, select Tools → Allow Remote Debugging
  4. Start Firefox, open about:config, set devtools.debugger.remote-enabled to true and restart Firefox
  5. In Firefox, select Tools → Web Developer → Connect…
  6. Fill in connection details in case you changed anything, otherwise localhost port 6000 should be fine
  7. Now you should get a list with “Main Process”. Click on that

And that’s it! Now switch to the debugger tab in Firefox, and after a short load you will start seeing scripts and can set breakpoints. I will be improving support during the next weeks, so other tools can also be used. Track my progress in bug 876636.

As I’ve used the term “Remote Debugging” more than once in this post and it has already come up on the bugtracker, I will also tell you a little about privacy. It may sound like we are opening doors here so that anyone who might like to connect to your Thunderbird instance can control it. That is not at all true.

First of all, remote debugging is turned off by default. If you don’t do anything about it, then you won’t even notice its there, nor will any attacker. If you do enable remote debugging via the menu, either on purpose or by accident, there is another preference guarding you called devtools.debugger.force-local. The default value for this preference is true, this means that even with “Remote Debugging” enabled, only connections from localhost (i.e your computer) will be accepted. If you decide to circumvent this too by setting that preference to false, there is yet another wall to save you: If a remote debugger attempts to access your computer, you are presented with a dialog to accept, decline or even disable remote debugging. If you decline or disable, no harm is done.

If you have any further concerns regarding privacy, please do comment or contact me.

About these ads

8 thoughts on “The Thunderbird (Remote) Debugger is alive!

  1. In search of a less risky way to connect debuggers to Gecko-based debuggees, we’ve been toying with the idea of adding support for Unix-domain sockets to the XPCOM socket components. (The patch is surprisingly small; let me know if you’re interested.) Then, the debugger server could create a Unix-domain socket in the profile directory: ordinary filesystem permissions would keep it secure, and the profile.ini file would enable a nice user experience when connecting the debugger. This would leave Windows out in the cold, but there’s no harm in doing what one can.

    Thanks for the kind words for the DevTools team! I’m really glad to hear it’s working out.

    • Well, personally I think the number of barriers before a malicious user can control Thunderbird are sufficient. I just included this section to calm other users and developers.

      One thing that might come up is that on a multi-user system, localhost connections are not secure either. But unix sockets won’t fix the problem. What we could do is always prompt if the connection should be allowed, but for the more common case of single user machines, this will be rather annoying.

  2. The question I have is does this open Firefox to attack in any way because step four?

    If you want to solve the unlikely problem noted you could make the pref only last for the session in Thunderbird. The user would have to select Tools → Allow Remote Debugging each time they wanted to use it which, in a way, might not be a bad idea anyway.

    • No, the pref is used slightly different in Firefox. As the developer tools UI is integrated into Firefox itself, there is no need to remote-debug a Firefox instance. Therefore the preference is only used to enable the “Connect…” menu item in the Web Developer menu.

      I personally would rather have the preference persist, otherwise if you are debugging something you would have to enable the debugger each time you restart Thunderbird. Using a debugger will keep you from restarting every time to add debug statements, but its still often enough for this extra step to be annoying.

      As I’ve mentioned, I don’t see a security risk in the way it is implemented now, there are enough prompts and preferences to protect you from attackers.

  3. Pingback: Thunderbird wird kompatibel mit Firefox-Entwicklerwerkzeugen - soeren-hentzschel.at

  4. Hey Philipp great work! I\have been an avid user of Venkman since I started to write Addons 5 years ago and I liked its ability to configure it almost like afull blown IDE; my question is: will it work on slightly older versions of Thunderbird / SeaMonkey / Postbox or would we be stuck with Venkman there. and connected to the answer, If it is client/server architecture would it be possible write an Addon that takes care of the “server” part in older xulrunner applications?

    • Hey Axel,

      unfortunately devtools is a moving target, they innovate pretty fast. Some of the code I wrote depends on a bug they just fixed a week ago. With a little work it might work for older gecko 24 nightly builds, but from trying the latest Seamonkey nightly builds (which are not gecko 24), the devtools server is missing completely. With a little more work it might be possible to package the whole devtools debugger server code, but I don’t know how the interactions with the js debugger api are and making it work on older versions is likely out of scope for the project.

      Philipp

  5. Pingback: Thunderbird Developer Tools Wrapup | Philipp Kewisch

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