~robcee/ more than just sandwiches

New Devtools Peer: Anton Kovalyov

Yup. That’s right. Anton’s a peer now. Send him your review requests!


Posted
20 December 2012 @ 12pm

Tagged
devtools, Firebug, Mozilla

Comments Off

Firefox Debugger Search Features

One of the great unsung features of the Debugger is the built-in search facilities by Victor Porof. They started out simply-enough with a search field for filtering which scripts were displayed in the drop down. However, as of Firefox 18, this little search box has gotten some Super Powers.

View of the Search Field in Debugger

It still acts as a filter if you just start typing. The search field will limit the files that appear in the drop-down to files that include the substring. But if you use one of the listed operators, magical things will happen!

! = Search in all files (Cmd/Ctrl+Alt F) – This is Super Search. You can search all of the loaded script files for a given string. Useful for finding references to variable or function names across your project. Hitting Enter after your search takes you to the first result. Hit Enter again and it advances to the next occurrence and so on.

# = Find in this file (Cmd/Ctrl-F) – Search the currently-loaded file for occurrences of a string. Basic search. Hitting Enter behaves the same way as above taking you to the next occurrence.

: = Jump to line (Cmd/Ctrl-J) – go to the line number in a file. Useful for rapid navigation. Also note that the up/down arrows will let you move through the file without explicitly focusing the editor from here.

It’s worth noting that you can combine these in the form “filefilter#string” or “file:xxx” for line number.

* = Filter variables (Cmd+Alt-V). This one’s new (in Firefox 19, currently in Aurora). If you’re on a breakpoint and the variables view is visible, you can filter the contents of it with this search operator. Sweet.

… and, in a few days, when bug 762160 lands just in time for Firefox 20,

@ = Find Implementors. Locate the definition of a function across all scripts. If there are multiple definitions, it will present a file-list for your consideration.

Note the keyboard shortcuts next to all of these and visible in the palette. Cmd/Ctrl-P focuses the search field (a nod to the Sublime Text editor which has a powerful, operator-driven search capability) to get you searching quickly while using the Debugger. You will need to have the debugger itself focused for these keys to be in effect, otherwise, you’re likely going to encounter browser shortcuts that do different things. Also check out the docs if you want to read about some of the remote capabilities of the Debugger.

Happy Debugging!


New Devtools Peer: Victor Porof!

While I was eating my sandwich and mulling this blog post, I saw this roll by on the Toronto office dashboard:

(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! :)


Firefox Devtools: hax

Last week, the Firefox Devtools teams got together in London for some together-time. We kicked the show off on Tuesday with some lightning talks, followed by hack sessions over the rest of the week. As always, it’s incredible getting together with everybody — I’m kind of a fan. We’ll be finishing things we worked on this week for the next couple of months and it will be awesome.

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!


Posted
24 September 2012 @ 8am

Tagged
devtools, Firefox, Mozilla

Comments Off

New Devtools Peer: Mike Ratcliffe

We’ve added a new peer to the Devtools Module: Mike Ratcliffe! Please send him all your reviews for the Inspector and Style Panels. He will help you.

Congratulations, Mike!


A Bug Story: Debugger Breakpoints and Page Reloads in Firefox

What you need to know: If you set a breakpoint in the Debugger in Firefox 15 and then hit “Reload”, the Debugger is going to shutdown. This has been fixed in Firefox 16.

And now the story…

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

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.


WebConsole’s $() convenience function: querySelector

tl;dr If you’re used to using $("id") in the WebConsole to lookup nodes with a given id, prepare to get used to doing it with $("#id").

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.


New DevTools Peer: Heather Arthur

We’ve added Heather Arthur to the list of esteemed peers in the DevTools code module. Heather’s been contributing to Scratchpad, providing session restore support, the Inspector adding pseudo-class lock capabilities and has been giving great feedback on patches. Even if she wasn’t an expert on machine learning and feline face detection in images, adding her as a peer would be an easy decision to make.

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


Posted
25 June 2012 @ 7pm

Tagged
Code, devtools, Firefox, Mozilla

Comments Off

DevTools Hackday June 26, 2012

We’re having a DevTools Hackday tomorrow, June 26th to create some commands for the newly-landed Global Command Line Interface. (Joe blogged about it here). It’s still new and waiting for you to write some excellent new commands for it. Got a thing you’d like Firefox to do? Feel like hacking a little Browser JS? This is the place to do it.

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.

 


Bookmarks Deiconizer, userChrome edition

A couple of years ago, I made a simple addon to remove the icons from bookmarks in the bookmarks toolbar in Firefox. It was a fun hack, but I knew then that it wasn’t the right way to do this. Nevertheless, easy is the enemy of perfect (or something) so I kept on using it, and AMO kindly kept on updating it when new versions of Firefox were released.

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.


← Before