November 13, 2012
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.
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.
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.
November 12, 2012
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.
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.
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.