OK, so if you build from the remote debug repo, there is a
DebuggerUI global on each navigator:browser chrome window (same scope
you'd normally be able to get at gBrowser from).
DebuggerUI has two methods of interest for you:
startDebugger() will fire up a debugger on the currently-selected tab
(due to some unfinished business, you can't start debuggers on
arbitrary tabs - only the currently-selected one). It will return a
debugger pane object (I'll get to that in a minute).
getDebugger(aTab) will return the debugger pane for the given browser
tab. I suggest calling it with gBrowser.selectedTab to get the
debugger on the currently-selected browser.
The debugger pane object keeps an eye on the html debugger UI. The
most interesting thing it has at the moment is a property called
"activeThread" which accesses the ThreadClient object for the
currently-running debugger. The only interesting method the
ThreadClient currently has on it is resume(), which will resume a
thread already paused at a debugger; statement. I would suggest that
you check the ThreadClient's state property to make sure it is
"paused" before trying to resume - it won't fail usefully right now.
This is all very very rough, but hopefully it'll give you something to
play with. Things should tighten up over the next week or two, and I
intend to dangle more useful commands/objects off of DebuggerUI that
should be useful for the command line.
See this patch: https://hg.mozilla.org/users/jwalker_mozilla.com/gcli-patches/file/e875c35a52c5/bug659885-debugger.patch
(which depends on the other patches in the patch queue, but which should apply cleanly over http://hg.mozilla.org/users/dcamp_campd.org/remote-debug/
Marking verified because there is no UI proof that the bug is fixed. The proof is in the code.