Update: if you’ve enabled the correct preferences, you can now use the --jsdebugger commandline flag to open the debugger immediately! You can also use this flag with mochitests. For more info, see my new post.

Earlier today, when I was still sound asleep, some of the students from the MSU capstone project that Jared and I are mentoring asked about debugging their add-on’s JS. Rather than just answering them, I figured I’d write a blogpost as perhaps the information is useful to others as well.

While there is ongoing work to make debugging add-ons built with the SDK a more natural experience, you can already debug browser and add-on JS alike using the Browser Debugger. In fact, while it’s not very intuitive (and again, there’s a bug for making that better) you can also use the Browser Debugger to debug mochitests. I have already been using this method to figure out what broke in recent test failures on the UX branch, and am pleased to have something more robust than dump statements to figure those out.

Generally, here is how you start using the Browser Debugger:

1. Open the Firefox Developer Tools Toolbox (Tools > Web Developer > Toggle Tools in the menus)
2. Click the little ‘gear’ icon in the toolbox to open the settings page.
3. Toggle the “Enable chrome debugging” and “Enable remote debugging” checkboxes. (you may need to scroll down in the toolbox pane to see these)
4. You can now close the toolbox, and either restart Firefox as the checkboxes suggest… or just open a new window.
5. There will now be a “Browser Debugger” item in the Web Developer submenu under Tools (sadly, there is no keyboard shortcut). Use it to open the debugger.
6. The Browser Debugger starts another Firefox process to remotely debug your existing Firefox process, and your existing one will therefore prompt you whether you want to allow access to the debugger (as doing so essentially gives full control of the debuggee to the debugger). Click “OK” in this dialog.

Now the browser debugger’s list of source files should start filling up. You can use the debugger much like you’d use the web debugger that is in the Toolbox: filter for sources, or even search through fulltext of sources to quickly find what you need, set (conditional) breakpoints, add watches, etc.

For mochitests, the situation is much the same except that, if you’re like me, you’ll quickly get annoyed because you get to go through the steps of enabling and starting the debugger manually every time. So I filed a bug and attached a patch to at least eliminate the opening of new windows, but got stuck trying to get it to pass all the tests.

In any case, you can start your test(s) with the --no-autorun option, and then go through the steps outlined above (opening a new window instead of restarting). Make sure you close the toolbox and the extra window, as these might otherwise interfere with running your tests. When you’re done setting your breakpoints and such, click the button in the mochitest window to start running your test(s). Happy debugging!

TL;DR: if you own/wrote code that adds an event listener for the "load" event on a tab, doublecheck that you’re listening for that event on a tab’s <browser> element, and not on the <tab> (eg. the value returned by gBrowser‘s selectedTab property).

In the past two weeks some of us on the Firefox front-end team have been working to get the UX tinderbox builds green again. When we initially started work on Australis, we broke a couple of tests and in the interests of moving forward those were not immediately fixed – we were on a branch, out of the way of everyone else, and it wasn’t our number one priority. Over time this resulted in pretty orange trees, and so we recently moved to fix all the tests we’d broken and return the tree to a functioning, green state.

Although some tests did catch bugs on our side, in general we found subtle bugs in existing tests, which we have (helped) fix both on mozilla-central and the UX branch. One of those that I figured deserved a blogpost of its own was a pattern that tended to look roughly like this:

let tab = targetBrowser.selectedTab;
let win = tab.linkedBrowser.contentWindow;
let expectedReadyState = aURL == "about:blank" ? ["interactive", "complete"] : ["complete"];

if (aOnload) {
  let handler = function() {
    if (tab.linkedBrowser.currentURI.spec != aURL ||
        expectedReadyState.indexOf((win.document || {}).readyState) == -1) {
      return;
    }
    tab.removeEventListener("load", handler, false);
    executeSoon(aOnload);
  }
  tab.addEventListener("load", handler, false);
}

Unfortunately this code broke with the Australis changes, which include removing the empty favicon for pages which don’t have one. The bug in the code may not be immediately obvious, but what the code was doing was adding an event listener on a tabbed browser’s <tab> element (the leaf in the tabstrip at the top), rather than the corresponding <browser> (containing the actual page). Why did that work at all? Well, the tab element contains an image: the page’s favicon. When that loaded, a load event bubbled up. As we’re removing the favicon if the page doesn’t have one, rather than replacing it with an empty placeholder as we do on current versions of Firefox, no such event fires for pages without a favicon, and the relevant tests/code broke completely in Australis (for some of these tests, it is quite possible they caused occasional random orange before).

The manual checking of the page’s readyState is a clue that this isn’t the best way to detect when the page has loaded. Instead of using tab.addEventListener, use tab.linkedBrowser.addEventListener (and the same for removeEventListener, of course).

I’ve attempted to audit the mozilla-central tree for this kind of code, but I may not have been thorough enough by just grepping for things like tab.addEventListener. If you have written code depending on tab loads, be it in tests, or add-ons, or elsewhere, doublecheck how you detect these events!

Today, Mozilla celebrates its 15th birthday. By a cunning plan sheer coincidence, today is also my first day as an employee, after being involved with the project for a little over 8 years. I’m extremely happy with everything Mozilla achieved in the years behind us, and after a period of being a little less active, I’m pleased to be able to help fulltime in the time to come.

I’m in the Firefox Desktop team, and I’m excited! I’ll (continue to) see all of you around, I’m sure (and will be in Mountain View between April 8th and 20th, if that helps).

Just a short note, quite some time ago some trunk changes broke ChatZilla. Accessibility also required some changes. All of these fixes have happened (thanks to dbaron for helping out with the layout fix) – but there has not yet been a release. Seeing as we’re getting close to 3.5, I thought I should note that those affected by these issues (say, people on 3.5b4) can download a nightly ChatZilla build here. New builds appear there after every (set of) change(s) in CVS. This should fix any compatibility issues. If it does not, please file a bug.

Edit: ChatZilla 0.9.85 (released some weeks ago…) has all these fixes, and will work fine with 3.5. Oops! 🙂