Since bug 758696 landed, the remote debugger server won't open a listener unless devtools.debugger.remote-enabled is true. This pref is not true by default for B2G, so Marionette fails to load. I'm going to land a patch on m-c to set this pref on B2G so we can get tests running again. However, longer term, what's the right solution? I'm not sure it makes sense to share a single pref among all consumers of the remote debugger server, especially given that the current code also shares this pref between a particular implementation of a remote debugger (http://mxr.mozilla.org/mozilla-central/source/browser/devtools/debugger/DebuggerUI.jsm#451), and dbg-server.js, which all implementers have in common. Maybe openConnection() should accept an isEnabled callback as a parameter, which would allow implementers to define their own mechanism for enabling/disabling? This seems consistent with the way that init() and initTransport() accept an aAllowConnectionCallback parameter. Otherwise, enabling Marionette will enable the remote-debugger (at least potentially) and vice versa, and I'm not sure that's what we'd always want, although maybe it is.
I just landed this patch as a (probably) temporary measure to get Marionette working again: http://hg.mozilla.org/mozilla-central/rev/26dcd1b1a208
Thanks for fixing this and sorry for the breakage. I should have thought of Marionette. The reason for the pref is a requirement from the security team to: (a) have a knob that keeps remote connections disabled until we are ready to roll them out (b) have a means for the user to disable the debugger server, perhaps after having enabled it in order to be assisted in debugging something from someone else You change is exactly what I would have done, had it occurred to me earlier. Since this is a security feature, I don't believe we want to deviate too much among products. All current and forthcoming users of the remote debugging protocol need this control, except Marionette: Firefox, Fennec and B2G, as well as NetMonitor/Firebug, Profiler and others, in the (not so distant) future.
Closing this based on comment #2