Last Comment Bug 659885 - Create GCLI command to support restarting the debugger
: Create GCLI command to support restarting the debugger
Status: VERIFIED FIXED
:
Product: Firefox
Classification: Client Software
Component: Developer Tools (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Joe Walker [:jwalker] (needinfo me or ping on irc)
:
: J. Ryan Stinnett [:jryans] (use ni?)
Mentors:
Depends on:
Blocks: GCLI-ENABLE GCLICMD
  Show dependency treegraph
 
Reported: 2011-05-26 01:42 PDT by Joe Walker [:jwalker] (needinfo me or ping on irc)
Modified: 2012-06-27 11:34 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-05-26 01:42:29 PDT
From dcamp:

OK, so if you build from the remote debug repo[1], 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[2] 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[3] 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.

-dave

[1] http://hg.mozilla.org/users/dcamp_campd.org/remote-debug/
[2] http://hg.mozilla.org/users/dcamp_campd.org/remote-debug/file/tip/browser/components/debugger/content/debugger-overlay.js#l45
[3] http://hg.mozilla.org/users/dcamp_campd.org/remote-debug/file/tip/toolkit/components/debugger/dbg-client.jsm#l193
Comment 1 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-05-26 02:52:06 PDT
Follow along:
https://hg.mozilla.org/users/jwalker_mozilla.com/gcli-patches/log/tip/bug659885-debugger.patch
Comment 2 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-05-27 02:40:45 PDT
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/
Comment 3 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-06-21 02:47:43 PDT
Marking verified because there is no UI proof that the bug is fixed. The proof is in the code.

Note You need to log in before you can comment on or make changes to this bug.