Chrome Debug Javascript Tutorial

Along with many others, I have to add Chrome to the list of browsers in which to test. Unfortunately, the JavaScript debugger in Chrome is lacking the visual representation I've since been spoiled with in Firefox and Safari. What they have is a text area you can get to from the Page menu or pressing Alt+`. It pops up a window in which you can debug the javascript with text commands.

There's not a lot of documentation out there for it now. I had this one up. There are some text commands available at all times, then more available only in Pause mode. I won't go through all the commands, just the ones I found useful.

When not paused in debug, these commands are avre
help
help on its own displays the commands available:
$ help
Status: page is running
Available commands:
break [location] <condition>
break_info [breakpoint #]
clear <breakpoint #>
help [command]
print <expression>
scripts

help with a command after it provides information on that command:

$ help break
usage: break [location] <condition>
location is one of <function> | <script:function> | <script:line> | <script:line:pos>

break
Sets up a breakpoint. Supposedly, you can set up breakpoints for line numbers, line positions and function names. For me, only the function name worked. When I tried a line number, it actually set up a breakpoint in a different file. Maybe if you have only one javascript file, the line number is used, but I just use the function name. I tried to specify filename and line number, but to no avail.

$ break DesignHeaderDOM
set breakpoint #1

break_info
By itself, lists information on all breakpoints:

$ break_info
Num breakpoints: 1
id=1, hit_count=0, type=function, target=DesignHeaderDOM

With a number, gives information on a specific breakpoint. Not too useful since it doesn't give any more information than break_info with no arguments. I suppose if you have pages of breakpoints it could be useful, but by that your point, your brain is probably already fried.

$ break_info 1
id=1, hit_count=0, type=function, target=DesignHeaderDOM

clear
Clears a breakpoint for the number specified:

$ clear 1
cleared breakpoint #1

print
print is more useful in Pause mode, but can useful for global variables and to see what a function returns. It would be useful if you could drill into all properties for a variable easily, but you can print out individual properties:

$ print 'hey'
hey
$ print 'a' + 'b'
ab
$ print wysControl //string var
wysiwygIframe
$ print wysControl.length
13
$ print GetWysiwyg()
#<an HTMLDocument>
$ print GetWysiwyg().body.innerHTML
DDDDDDDDDDD<h1>CCCCCCCCCCCcc<br></h1><div>DDDDDDDDD</div>
$ print TrimString(' test ')
test
$ print IsIE()
false

PAUSE MODE
Once you have breakpoints setup, you can make the javascript run on the site. I'm doing this by pressing a button to turn text in a wysiwyg into a header. My breakpoint is set up for the method. When the breakpoint is hit, the debugger window gets focus and shows the current line:

311: var doc= GetWysiwyg();

In Pause mode, the help now shows all commands now available:

$ help
Status: page is paused
Available commands:
args
break [location] <condition>
break_info [breakpoint #]
backtrace [from frame #] [to frame #]
clear <breakpoint #>
continue
frame <frame #>
help [command]
locals
next
print <expression>
scripts
source [from line] | [<from line> <num lines>]
step
stepout

print works as before, only now it can take in local variables as well.

Other variable helper commands:
args
Lists all arguments a method took in. Displays nothing if the method has no arguments. (It doesn't give a message like "No arguments passed in", so when you hit Enter and nothing happens, it actually did do something)

$ args
html = "test text!"

locals
Prints out the value of all variables defined in the method. All start out as undefined.

$ locals
selHeaders = undefined
headerTags = undefined
headerRange = undefined

After stepping through a little....
$ locals
selHeaders = #<an Array>
headerTags = #<a NodeList>
headerRange = undefined

Stepping through the code methods:
step : The equivalent of "Step Over"
next : The equivalent of "Step Into"
stepout : Gets out of the current method, takes you to line on which that method is called.
continue : continues executing til the next breakpoint. If no more breakpoints, breaks out of Pause mode.

The guide I used seemed to give up on these, but they actually work well.

Lets say this is my code:

function RunStuff()
{
var num= fi(5);
}

function f1(i)
{
return f2(i + 1);
}

function f2(j)
{
return j*j;
}

If I have a breakpoint on f1, The code will stop at the first line inside it.
- If I run next, it will run the next line and not go inside f2. Continuing to type next will debug RunStuff and on until there's no more to javascript to run.
- If I'm in f1 and type step, it will go inside f2. At this point, stepout will take me back to f1. stepout again will take me to RunStuff.
- At any point, if I want to stop debugging, I can run continue and either go to the next breakpoint or stop debugging.

source
At any point, if you want to get a good idea of where you are in the code, you can run source to see a 10 line snapshot of the code. Note the >>>>> in the line numbers for what line the debugger is currently on:

$ source
555: return text;
556: }
557:
558: function f1(i)
559: {
>>>>> return f2(i+1);
561: }
562:
563: function f2(j)
564: {
565: return j*j;

That's all for now. I still have to investigate, but that's what I've found on the first run-through. There's definitely a few things that would make it easier (even before a full visual interface)....
1. An auto-focus on the command line.
2. Just hitting Enter repeatedly to step through the code (or F10!) instead of typing in "next" every time
3. Printing out every property of a variable.
4. If I clear breakpoint 1 and 2, the next one still starts at 3. Not sure if I like this yet or not.
.... but for they time being, we can make do.

Also, if you play around enough, you're bound to see these: