File Under: JavaScript, Programming

Debug JavaScript With Venkman

In the first part of our JavaScript debugging tutorial, we talked about debugging methods that work in just about any web browser. These techniques are useful when you’re trying to get your script to work in a particularly troublesome browser. More often, however, you’re faced with some code that just plain doesn’t work, and you’re not sure why.

With a script debugger, you can pop the hood and study exactly how things work — the catch being that the only really robust debuggers exist only for Internet Explorer and the Mozilla family of browsers. But that’s OK. You don’t really care about browser compatibility yet; you just want the darn thing to work.

In today’s lesson, I’m going to show you how to use Venkman, Mozilla’s script debugger. It’s not really any better or worse than Microsoft’s Script Debugger, but it has the advantage on running on Windows, Linux, Unix, and Mac OS X. You can download it from Mozilla’s site. As with all extensions, you’ll need to restart your browser after installation. Once you restart, you should see a menu item named JavaScript Debugger under the Tools menu. Make sure to click on this menu item after you’ve loaded the page you want to debug. It also is a good idea to close any extraneous tabs before you start debugging.

The first time you open Venkman, you’ll be treated to a classic open-source interface that offers up eight panes in a single window. Don’t freak out just yet. You can rearrange the layout to your liking and get rid of the panes and elements you don’t care about. You can drag a pane around the window to rearrange things, and remove a pane entirely by clicking the X in its upper-right corner. To dock two panes together, drag one to the box on the left side of the other’s title bar and let go of the mouse button. The two panes will be joined, and you can toggle between them using tabs.

venkman1_sm.png

Venkman’s interface (Take a closer look)

The Loaded Scripts pane shows the script files currently loaded. By clicking the disclosure triangle beside a script file, you can browse to specific functions in the file. The Open Windows pane gives you a similar view, but further separates things by browser windows.

The Local Variables pane lets you peek at variable values as your code executes. More about this in a minute. The Watches and Breakpoints panes let you specify when to start debugging. And the Call Stack pane shows where you are in the code — that is, what function is executing and who called it.

That leaves two panes: Source Code, which shows your code as you debug, and Interactive Session, which gives you a command line to work with. You don’t have to use this pane at all, but if you’re interested in it, type /help to get a command reference.

Alright, now let’s do some debugging.

Stepping up

There are three main steps to debugging JavaScript with Venkman. First, we make the debugger stop where we think the problem lies, then we step through the code and observe it to see exactly what’s going wrong. Finally, we fix the problem.

The best way to jump into the debugger is to set a breakpoint. A breakpoint simply says, “When we reach this line, start debugging.” Let’s set one now.

Open our demo page and fire up Venkman. Look for demo.html in the Loaded Scripts pane. Look inside the file by clicking on the disclosure triangle and find the countTo function. Double-click that to pull it up in the Source Code pane.

See how in the left margin of the Source Code, there are dashes? Click the one beside the line that reads:

for (var i = 1; i <= number; i++)

The dash turns into a bright red B, indicating you’ve set a breakpoint. You can click it two more times to clear the breakpoint. (It toggles to an F along the way — this indicates a special kind of breakpoint that you don’t need to worry about just yet.) But leave it be for now and switch back to the regular browser window. Click the countTo button and it’ll throw you back to the debugger, only now you’ve frozen execution.

Notice that the Local Variables pane now shows our variables: i, number, and target. Because “target” is an object, you can dig into its properties like you did the source code files.

venkman2_sm.png

Venkman displaying object properties (Take a closer look)

You can use the debugger’s toolbar to control the flow of execution. The Continue button stops debugging entirely, and runs the rest of the script. The three Step buttons work in similar ways — they basically control whether you dive into subfunctions or not. Step Over skips past a subfunction call, while Step Into delves deeper. If you get too deep into things, use Step Out to jump up the next highest function call. If you click Step Out at a function that was invoked directly by the user, it acts just like the Continue button.

So go ahead and click Step Into a bunch of times. Watch how the i value changes as you loop through the for loop. Pretty nifty, eh? You don’t have to just sit there. Right-click the value of number and choose Change Value. Type in 14 and hit OK, then click Continue in the debugger toolbar. Indeed, it counts to 14 instead of 7. You can use this trick to simulate weird conditions in your script, or just to experiment to see how your script reacts.

Digging through an object to find a particular property can be cumbersome. Watches provide shortcuts to exactly the sliver of information you want to “watch” for. Right-click the empty space in the Watches pane and choose Add Watch Expression. Type in target.innerHTML and hit OK. When you step through the countTo function again, you can watch innerHTML get written to.

Watches can evaluate any kind of expression at all. Add another watch, but this time type (i == number). The debugger tells us it’s false. This is a pretty simple condition, but you could use similar ones to track all kinds of things while you step through your code. You can even save a set of watches for future reference. Just right-click the Values pane and choose Save Watch Settings. The item below it, Restore Break/Watch Settings, gets them back. Incidentally, there is a matching Save menu item for the Breakpoints pane.

Now that I’ve given you some toys to play with, go ahead and try them out with your own code. For more information on Venkman, try the official FAQ or even this guide, which goes into more detail than I have space for here.

Happy debugging!


Did you love this article? Did you hate it? Think you can do better? Send us your Feedback. Feedback submitted here will be considered for publication on Webmonkey or Wired News, so if you don’t want us to print your comments, please say so in your email.