What I Worked On During the DevTools Work Week

0

Last week, I was at the DevTools work week. For those of you who don’t know: I’m a member for the Jetpack team, which recently became part of the DevTools team, so this was the first time I met everyone on the team.

My primary role is that of platform developer, but good platform bugs for Jetpack have been hard to come by. DevTools, on the other hand, has dozens of platform bugs they would love to see fixed. As a result, this particular workweek was very exciting (and exhausting!)

Debugger Support

I spent most of my time hacking on bugs 808588, 816988, and 820012. These bugs are closely related, as they all amount to the same problem: we are currently unable to attach the debugger to certain scripts (Jim, if you are reading this, I’m sorry I used the word attach here). This particular problem also impacts the Jetpack team, since it makes it impossible to debug add-on scripts as well.

Panos Astithas already spent some time on bug 820012, and came very close to fixing it. The root of the problem was a bug in our algorithm for setting breakpoints. Panos wrote a patch to fix this, which partially solved the issue, but not enough for the problem to go away.

It took me some time to figure out what was going on, but in the end I decided to rewrite our algorithm for setting breakpoints completely. With this fix in place, we were able to attach the debugger to scripts loaded with nsIScriptLoader.

Unfortunately, we were still unable to debug add-on scripts, because another bug (bug 808960) makes it impossible to load add-on scripts in the debugger. In fact, half of the time, add-on scripts won’t even show up in the debugger in the latest Nightly.

To illustrate this, I created the most annoying add-on in the world. It listens for any tabs being opened, and automatically closes them again one second later. If we try to debug this add-on’s main.js script in the debugger, here is what we see:

As you can see, the add-on script doesn’t even show up. I created a patch for this problem too. With both patches applied, this problem goes away, and we are even able to set breakpoints in the add-on script, as you can see here below:

Being able to debug add-on scripts is extremely useful for add-on developers (it certainly is a lot nicer than console.log debugging!). Both patches already landed in Nightly, so you should be able to play with it right away.

One caveat though: it looks like one of my patches introduced a regression (bug 851836) that can cause Firefox to crash if you run into it. The issue is pretty rare though, and I’m already looking into it, so this problem should be resolved by the end of this week.

ES6 Modules

For those of you who are curious where we are at with ES6 modules: I also met up with Jason Orendorff during the work week. He is pretty overcommitted right now, so it was tough getting reviews from him for a while (I totally understand that by the way: one of the downsides of being awesome like Jason is that everybody wants your attention).

Unfortunately, as a result, most of the patches I wrote to add parser support for modules are now bit rotted (bug 568953), because of a refactor by Brian Hackett that splits the analysis and AST building parts of the parser up into separate parts. It’s going to take some time rebasing all of them and getting them landed, but Jason and I are going to look into that this week.

On the plus side, I also got a chance to talk to Jason about how module loader semantics are supposed to work. This part of the spec has been in flux for a while, but now seems to be stabilizing. Over the next couple of weeks, Jason and I will be translating this part of the spec into an implementation plan. Once we have that, we should be able to move forward a lot faster than we have so far.

Categories: Uncategorized

No responses {+}

Post Your Comment