Firefox Developer Tools for Mobile Devices

The Firefox Developer Tools team is working hard to improve the lives of developers targeting Firefox on Android and Firefox OS. We’ve made a lot of progress: our debugger was built with remote protocol support from the beginning, and our web console was recently ported. Others have good posts describing this stuff, so I won’t dwell on it here.

But we have a long way to go. Here are some of the challenges we have ahead of us. Some of them are close to finished, some haven’t been started yet. If you want to pitch in on any of these, come find us on irc.mozilla.org’s #devtools channel.

Developer Tools Window

As I described in my post about tools for browser developers, some of what we have to fix are relatively mundane UX problems: our tools are hosted in-tab and have nothing to tie them together when looking at a remote target. We have one-off solutions for all the remotable tools right now – attaching your JS debugger and your web console are two different actions.

The Developer Tools Window project and its associated Target API will tie this up. There will be one place to specify a debuggee, and all tools that are remote-protocol ready will share a window and connection information. There’s also work to be done to make the different tools share a single debugging connection.

This project is well underway. The first milestone of this project is aimed at Firefox 20.

Content Process Support

Firefox OS uses process separation for applications, and the debugging server doesn’t support that. For now you can get work done by disabling process separation for Firefox OS, but we’d like to do better than that. We don’t think this will require significant protocol changes, but it will take some changes. Each of the content processes will need to host a debugging protocol server. The toplevel debugging server will need to route messages to the right content process. We’re discussing our implementation plan in bug 797627.

Profiler Protocol Improvements

The SPS profiler works against remote debugging targets, but easily runs in to memory constraints. Some of the blame here is on our remote protocol implementation: it doesn’t make it easy to send large amounts of data efficiently. Work is underway to define and implement a data blob extension to the remote protocol. The current protocol change proposal is here and is being discussed here.

Inspector

Probably the largest piece of remaining work is getting the page inspector working over the remote protocol. The inspector is a somewhat large piece of functionality, encompassing:

• The navigation breadcrumbs
• The markup view
• The style views: rule view, computed view, and layout view
• The highlighter veil

All of these currently assume direct, synchronous access to the DOM (boo). Porting them is going to take some work, not all of which is entirely straightforward. This is going to be a big focus of the inspector team over the next few months.  We’ll keep you up to date with our progress.

The Other Tools

There are a few other tools that would be great to port to the remote debugging protocol, like the style editor and the scratchpad. These are a lower priority for the team at the moment, but porting them to the remote protocol should be relatively straightforward. If you’re interested in helping out, find us on #devtools.

Summary

Great tool support for Firefox for Android/Firefox OS is one of the highest priorities on the Developer Tools team right now.  Some of our core tools already work (the debugger and the web console), some are coming soon (SPS profiler), and we’re working hard on the rest.

Advertisement

Firefox and addon developers should set devtools.chrome.enabled

If you work on Firefox or addons, you should have the devtools.chrome.enabled pref set.  Use about:config or open up your Developer Toolbar and run “pref set devtools.chrome.enabled true”.  While you’re at it set devtools.debugger.remote-enabled.  Restart your browser.

What’s There Now

Command Line – calllog chromestart

While you have the developer toolbar open, you can try running “calllog chromestart chrome-variable gBrowser”.  This will show you all the calls in the current browser window’s global.  “calllog chromestart jsm resource:///modules/devtools/CssRuleView.jsm” will show all the calls in the inspector’s Rule View.  “calllog chromestop” will end the logging.  This was added in Firefox 17.

Scratchpad

With devtools.chrome.enabled, scratchpad will have an “Environment” menu.  Select “Browser” and your code will execute against the current browser’s scope rather than the current content tab.  This is useful for running small bits of code or prototyping whole features – see https://blog.mozilla.org/jorendorff/2012/03/26/loupe/ for an example of a tool built entirely in a browser scratchpad.  Scratchpad introduced the devtools.chrome.enabled pref way back in Firefox 6.

JS Debugging

By far the largest bit of work we’ve done for browser developers so far is the JS Debugger.  The pref adds a “Browser Debugger” menu item to the web developer menu.  This menu item fires up a new child Firefox instance communicating with the current Firefox instance over the remote debugging protocol.  Your source list will have every source that has yet been loaded by Firefox.  As new sources are loaded (during JSM imports, addon installations, etc), they’ll show up in the source list.  Find the source you want to debug, set a breakpoint, and go.  This was only recently added to mozilla-central, you’ll need a recent Nightly to see this in action.

What’s Coming Up

JS Debugging Improvements

The JS debugger is still rough for chrome development.  We have a few things we need to improve:

• Filtering by globals – there are a Lot of sources in the browser.  Filtering by global will help you think focus on things you care about (maybe a specific addon or JSM).
• Freezing the browser – the debugging server spins an event loop while paused at a breakpoint.  So the specific code you’re debugging won’t continue, but we don’t do anything to stop new events from being processed.

Developer Tools Window and the Target API

The toughest thing about pointing our inspector at the browser is a UI problem.  The inspector is hard-wired inside the browser window and there’s no way to tell it to look at anything else.

The developer tools window (which should land in Firefox 20) will let us gather all the tools in one place.  More importantly it adds some structure to how the tools find out what they’re pointed at, called the Target API.  By default there will be support for local tab targets (“debug the current content tab”) and remote targets (“connect to my b2g phone”).  With devtools.chrome.enabled, local chrome windows will be valid targets.

Not all tools will support all targets.  The inspector doesn’t support remote targets right now, and the debugger can’t support local chrome targets (a debugger isn’t much use if it’s frozen every time it hits a breakpoint).

The inspector, at least, will support local chrome targets very soon.

Bringing it All Together

So within a month or two, you’ll be able to use the key features of the Firefox Developer Tools against the browser itself.  It will be a somewhat hodgepodge experience – your JS debugger will be running in a different process and the inspector in the same process.

When the inspector can be used remotely, we’ll unify this experience.  The “Browser Debugger” menu item will be replaced with a “Browser Developer Tools” menu item of some sort, and you’ll have one window with a complete developer tools suite.

But progress toward a remotable inspector is a different blog post.

Developer Tools at the Firefox Work Week

Last week the Firefox team got together for a week in our Toronto office.

I gave a talk about the state of the team.  The slides are here, and give a quick overview of the work we’ve done so far this year, and some of the work we have planned.

The scratchpad was a pretty popular target for hacks during the week:

• Jason from the spidermonkey team wrote a patch to expose the Debugger object to chrome scratchpads.  You can user this to build one-off debuggers while writing your code.
• Irakli from the Addon-SDK team showed off his new addon context for the scratchpad.  This will make prototyping addon-sdk addons even easier.
• I put together an addon for publishing and fetching scratchpads to/from gist.

Honza, Joe, and Mike put in a lot of work planning and hacking the HTTPMonitor.  Honza wrote a blog post about the HTTPMonitor and the work going in to it.  Honza demoed remote monitoring of  Fennec loads on the first day of the work week, having been lent a phone a few hours earlier.

Paul, with the help of the Desktop Firefox team, started on a Responsive Mode.  You can watch the video here and follow progress on the bug.  Paul is looking for more feedback here.

Rob, Victor, Panos, and Jim kept pushing on our Debugger, getting it closer to shipping and closer to landing chrome debugging support.

On Wednesday the team had dinner at the CN Tower.  The waiter took our picture, and Rob posted it here.

The developer tools team is working hard to build great stuff, and these work weeks are a great time to build fun stuff, plan large upcoming work, and hang out with an incredible team.  Thanks to everyone involved, I had a blast.

Firefox Developer Tools London Meetup

My first day with the Firefox Developer Tools team was during a work week a bit more than a year ago. The five people in the room (and two that couldn’t make it) were working hard to ship their first feature: the Web Console that shipped with Firefox 4.

Last week we met at the new Mozilla London space for our first work week since that meetup a year ago. This meeting had a completely different tone – we’ve shipped quite a few features since then, and we have loads of improvements and new features coming soon.

It was also much larger. The core developer tools team has grown since that last meeting, and everyone on the team was able to make the trip this time. And on top of the core team, we had quite a few people from other teams along: people from the security, visual design, and javascript engine teams brought our total from five attendees last year to eighteen this year.

We took a group photo, which you can see here.

On Tuesday we had a few talks. Some highlights:

• Jim Blandy gave a talk about the new Spidermonkey Debugger API. Jim will be doing this talk again (hopefully at the Firefox work week in April), and we’ll make sure it’s recorded next time.
• Tanvi Vyas and Mark Goodwin from the security team gave a talk about new tools for surfacing information about security APIs like CSP and HTTP STS. (slides)
• Mark Surman showed us some educational authoring/inspection tools Mozilla people are building, including Hackasaurus and PopcornMaker.
• Piotr Zalewa talked to us about jsFiddle.

The rest of the week was spent hacking:

• Rob, Panos, and Victor from Rob’s debugger team worked with Jim and Jason Orendorff from the javascript engine team to point our script debugger at browser chrome. I’m waiting on a real blog post for that work, but here is Rob’s teaser.
• Lucas Rocha poked his head in from the other side of the London office with a patch to make our debugger work against fennec running on a phone.
• Paul built a magnifier from scratch in the scratchpad. The feature is neat, but the way Paul put it together is really interesting. jorendorff wrote a post about it.
• Firebug hacking: Honza and Joe put together scripts to build firebug with dryice, and Heather posted a pull request to use the new pseudoclass lock API in firebug.
• Tanvi and Mark followed their talk with a patch to call out mixed content in the web console.
• Cedric put together a proof of concept for live scratchpad evaluation.
• I put together code to expose the debugger API to scratchpads.

Not bad for three days of hacking, eh?

It was particularly great to meet people that I’ve had the pleasure of working with for a long time, but hadn’t yet seen face-to-face. I’m really lucky to work with this team, and look forward to seeing most of them again at the Firefox work week in April. Huge thanks to everyone that helped organize (particularly Ashley Sullivan) and attendees from other teams that helped make this work week so successful.

Edit: Added Piotr’s jsFiddle talk.

How I Started in Free Software

When I was in college, I wanted to help with something on GNOME‘s website. I don’t remember what it was. At the time they were handing out CVS accounts like candy, so I was given one to check in a quick fix.

A few months later I was goofing off with a dumb little gtk project. My bash profile still had that CVSROOT and I accidentally imported the project into GNOME’s cvs.

I was totally embarrassed and I emailed Miguel to apologize and ask him to remove it. He refused, and asked me to keep working on it there. Things happened from there, and it eventually ended up changing the entire path of my professional career.

Anyone else have a good story about how they got started?