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.

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.

4 Responses to “Firefox and addon developers should set devtools.chrome.enabled”


  1. How difficult would it be to use the browser debugger to debug Thunderbird, SeaMonkey or other XULRunner applications?

    • campd Says:

      It would take work, but not too much work. b2g and fennec each provide custom root actor implementations that you could use for inspiration (look for files named dbg-browser-actors.js). Use a listTabs implementation that creates a ChromeDebuggerActor (similar to the toolkit/devtools/debugger/dbg-browser-actors.js implementation of listTabs).

      You also might need to do a little work to convince the debugger UI to use that chrome actor when starting it from the Remote Debugger menu item.

  2. Leon Victor Says:

    The important thing I experienced with this is JS Debugger and the improvements did in that helps me to identify the bugs, errors in my webpage.


  3. It is not my first time to visit this web site, i am browsing this
    web page dailly and take good facts from here every
    day.


Comments are closed.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: