Firefox and addon developers should set devtools.chrome.enabled
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.