(That’s from Chris Atlee‘s Try High Scores page, if you were wondering. It’s cool.)

Check out third place, just edging out bsmith and gaining on masayuki.

Now, before you get all uppity and start accusing Victor of abusing the Try servers, know this: He’s been making great progress beating down our intermittent failures. Earlier this year, we shipped the 3D View which Victor implemented. It has 21 bugs filed on it which either means it’s extremely solid code (it is) or nobody’s using it (they might not be).

Well, that’s not all! Victor has also been doing a fantastic job on our Debugger front end. Just recently he’s completed a massive reorganization of the front-end code making it better and some useful pieces reusable for our other tools. Expect to see some improved Variable Views in our object inspectors, web console and scratchpad very soon as a result.

Please join me in congratulating our latest Firefox Developer Tools Peer by sending him code reviews for the Debugger, Tilt and whatever else you might have for him.

Thanks, Victor!

My lightning talk was an example of how you can write a Jetpack addon using gozala‘s Scratch-kit. I cooked up a non-working demo the morning before our talks and managed to get the addon prototype to a state where it kind of works. The addon itself is ultimately intended to be a button you can use to share posts on app.net (the I-have-fifty-dollars social network).

The Code looks like this:

The remaining time was spent hacking on bigger targets. I got to sit down with Benoit Girard and work on integrating a JS-only version of the SPS Profiler. In two days, we were able to put up patches for a stripped-down version replacing the addon and integrating the Cleopatra web app. We’re going to be continuing that work over the next little while to get it polished and tested. See bug 795262 to track our progress.

Watch planet.mo and the Devtools blog for more throughout the week!

Congratulations, Mike!

And now the story…

A couple of weeks ago, Dave Herman (aka @littlecalculist) CC’d me on a tweet. That led to this tweet:

@littlecalculist That was an earnest question, not snark. I couldn’t get debugger statements or breakpoints to work.

— Tom Dale (@tomdale) August 16, 2012

Initially, I didn’t know what was going on. I’ve been using the debugger daily but not in any deep way. I’ve seen breakpoints and debug statements work regularly. After a couple more exchanges, Tom pointed us to a video of his situation which was setting a breakpoint early in his script and then hitting reload, expecting the breakpoint to hit during the parsing phase.

This too I know I’d seen work, so there was definitely something wrong so I filed bug 783393. Panos wasn’t around so I asked Dave (Camp) what he thought and he poked around at it for a bit. He determined that we had a nasty race condition in our Debugger reattach mechanics. Dave still knows the Debug Protocol code as well as anyone (despite his protests) and he agreed to hack up a patch for us.

By now it’s late Thursday, August 16th. Twelve days before the merge.

What’s a merge you ask? That’s where we take our Nightly browser and push it up to Aurora. Aurora becomes Beta and Beta becomes the new Firefox. Yes, that’s right, we have 4 branches we maintain and shuttle through our release processes. Who takes care of each of these channels? Our release managers!

By Monday, dcamp had a decent patch to deal with the race condition. It required rewriting the way the Debugger detaches and reattaches to content on navigation. It had gotten a little complex, but it was something. Panos was back from the beach and we brought him up to speed on the story and handed the patch over to him. He’d just gotten back from the beach and seemed very relaxed.

Dave and I decided it would be best if we had a patch to disable the debugger on reloads and navigation in Beta. The likelihood of the full fix making it in was minimal, so I wrote the tiniest patch I could think of to do it. A total hack job. Dave had switched back to getting his new markup panel for the inspector into a shippable state. I could have sworn I heard the sepulchral undertones of Norwegian metal when I spoke to him in IRC.

By Tuesday, Panos was still grinding on the patch, fixing failing tests, rewiring parts of it and dealing with the fallout. The patch was mutating a little but Panos was improving it. The beard he’d grown the previous week on the beach was starting to itch but he clung to it. I think it helped him code. Kept him in a beachy state of mind. I pung Lukas Blakk to tell her what was going on and warn her that we were going to have to try to get something into Beta. We didn’t know what at that point because we weren’t sure we’d be able to port Dave and Panos’ fix that far forward.

I gave an update in the engineering meeting that went something like, “yeah. breakpoints in reload. not so much. working on it…” Afterwards, Lukas, Dave and I went through our freshly-cooked plan to ship the shutdown patch on Beta and the real fix on Nightly and Aurora which should be ready Any Minute Now. Lukas agreed this was a sensible approach. The alternatives were waiting for a patch that might not work on Beta or kill-switching the feature. We felt the Debugger was still useful enough without reload breakpoints working that it was worth shipping and I still believe that’s true. It just might require some additional debugging strategy or a jump to the new Beta or Aurora (where most devs should probably be anyway).

Wednesday. The patch was not ready yet. I started wondering if we should kill reloads on Aurora as well. I was getting a little scared, but Panos’ beard gave me hope. Then he shaved it off.

Thursday and we had our tests passing. The patch was ready, but not quite perfect. I encouraged us to move ahead with an imperfect patch. I reviewed a couple of things Victor had been working on. Little things like full script search and some collapsible panels in the debugger. Nice things he’d been patiently waiting to land.

Friday the patch was ready. Panos landed it amidst a tree of fire and watched the tests pass. It was glorious. I conferred with Lukas one last time to get preapproval for Aurora. I’d be landing it on Saturday, but that was cool. Stuff was landing. The devtools team was pushing features into the fx-team repository at a shocking pace. It was like that scene from Mission Control when the rover touched down and everybody including mohawk guy were awkwardly high-fiving and cheering. Yes it was that good.

On Saturday, Victor and I hung out and rebased Panos’ patch for Aurora. Fixed some tests. Made it work. Victor did most of the work. He’s good that way.

What’s really impressive to me is how this whole thing unfolded from start to finish. An innocuous tweet about one feature from someone outside the project could turn into a flurry of activity and have such an excellent resolution in a very short time-scale. Everybody worked really hard on this thing and if we’d shipped without those breakpoints working on reload, it would’ve undermined people’s confidence in it. I think this extra effort makes the Debugger that much more usable. I’m also really impressed with how Dave, Panos, Victor, Mihai, Lukas and Nick dealt with all of this. It’s a huge privilege to work with such amazing and talented people.

Also, thanks to Tom Dale for reaching out to us and asking a question. This couldn’t have happened without him and Dave Herman pointing us to it.

So yeah. We have a JavaScript Debugger now. It’s in Firefox 15 and up. You should probably use Beta or Aurora for serious debugging. I hope you like it.

There was a short discussion in the #firebug channel in IRC this week about the usefulness (or lack thereof) of the $() convenience function in the Console (Firebug’s, Firefox’ Web Console, Chrome’s Console, all of ‘em). They currently map to getElementById. Way back in ought-five, when Firebug was still a twinkle in Joe Hewitt’s eye, getElementById probably made more sense than it does today. These days, you don’t see a lot of nodes in a webpage carrying the ID attribute. There are probably some good reasons for this. Having a rich selector API in all browsers is certainly at the top of that list of reasons.

Paul Irish’s initial suggestion was to use querySelectorAll for $(). I felt this would be kind of annoying for users used to getting back a single node. We compromised on using the querySelector function for $() and leaving querySelectorAll on $$(). I think this gives them both a useful purpose and will provide the least breakage for users of $().

It’s a pretty innocuous fix and it’ll be in Firefox Nightly sometime this weekend. Some of the discussions this has spawned have been pretty interesting. It would be nice to have a better iterable interface on NodeLists for example (Array.forEach(list, function...) is way more annoying to type than just list.forEach(function...)). With a proxy object, we could combine the results of $() and return a NodeList in the case where there were non-unique matches and return a single element if there were an exact ID match (without having to prepend the octothorpe to the query).

Leave a comment with your own magical $() wishes or ideas.

You can see the initial discussion in bug 778732. Firebug’s issue 5764 and Webkit’s bug 92648.

Please join me in welcoming her to peerdom by sending her lots of patches to review!

Join us in IRC in #devtools on irc.mozilla.org.

There’s an MDN page that shows you what you need to get started. It boils down to this simple template you can run in a browser Scratchpad:

Components.utils.import("resource:///modules/devtools/gcli.jsm");

gcli.addCommand({
  name: 'hello',
  description: 'Show a message',
  params: [
    {
      name: 'name',
      type: 'string',
      description: 'Who to say hello to',
    }
  ],
  exec: function(args, context) {
    return 'Good morning, ' + args.name;
  }
});

I’ll be hanging out in 10-Forward in Mountain View if you want to meet up and get your HACK on. There will be snacks.

All was right in the world.

Then this week, some changes to Firefox’ toolbar caused the add-on to stop working. It still works if you do the enable-disable dance in the Addons Manager, but that’s no way to live everytime you restart your browser or open a new window. Something had to give!

To banish your bookmarks icons forever, add the following to your userChrome.css file (it’s in your Profile Directory‘s chrome subdirectory). If it doesn’t exist, create a new file named userChrome.css and add:

scrollbox#PlacesToolbarItems > toolbarbutton.bookmark-item > .toolbarbutton-icon {
  display: none;
}

Update: If you’re on Windows, you’ll probably want to include:

scrollbox#PlacesToolbarItems > toolbarbutton.bookmark-item > .toolbarbutton-menu-dropmarker {
    display: -moz-box !important;
}

This makes the little folder drop-down arrow visible on folders.

Save the file, restart your browser and your icons should be gone forever.

Last week we got the whole DevTools group together in beautiful, sunny London England to hang out and hack on a few things. Sunny? Yeah, unexpected, but made for some great picture taking.

At the risk of saturating Planet with developer tools-related updates, there was some pretty magical stuff happening.

Our own Debugger task force put together the start of something wonderful. It’s a very early prototype at the moment, but with a bit of bug filing and polish, I think we’ll be able to get it into something that’s functional and not hard to look at in the next few weeks.

stay tuned…