We have the ability to start a debugging server and to attach the Firefox debugger to remote processes. We should hook this up to xpcshell tests. robcee has given me the following pointers: Cu.import("resource://gre/modules/devtools/dbg-server.jsm"); function startDebuggerServer() { // Start the server. if (!DebuggerServer.initialized) { DebuggerServer.init(); DebuggerServer.addBrowserActors(); } // For an nsIServerSocket we do this: DebuggerServer.openListener(6000); // A connection on port 6000. } startDebuggerServer(); https://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/debugger/server/dbg-server.js https://wiki.mozilla.org/Remote_Debugging_Protocol https://mxr.mozilla.org/mozilla-central/source/browser/devtools/debugger/debugger-controller.js We /might/ be blocked on bug 820012. We'll see. I'm going to look at this in more detail while I'm here at the Firefox Work Week.

dcamp helped me hack up an XpcshellActor for the debugger server. Unfortunately, we are still at roughly the same place we were last year with bug 750364: we can't add a debuggee while it is on the stack. Essentially we need to say "start debugging this test." However, since we are loading the test file in the same global as head.js, we can't add a debuggee from head.js without getting the aforementioned error. As far as dcamp and I could come up with, we have the following options: a) Refactor head.js so tests execute in a separate global (i.e. a compartment or sandbox) b) Hack up xpcshell.cpp or similar to spin the event loop. Introduce some other global to install head.js in the debugger while head.js isn't on the stack. a might be easier but it may break some xpcshell tests. Who knows.

Yeah, having the event loop on which the debug server depends run in the debuggee is... problematic. And if the event loop is in JavaScript, then it must be called by something, and whatever that is needs to be a non-debuggee as well. I wonder if some xpcshell tests run their own event loops. Those would need to be reworked.