Netscape Navigator 7 Venkman Debugger

Like IE, Netscape Navigator 7 has a debugger of its own called Venkman. This provides all of the features and debugging power of the IE version; for example, we can step into, over, and out of our code, work with breakpoints, and access a call stack window.

Following is the main home page for Venkman:

http://devedge.netscape.com/viewsource/2002/venkman/01/

To install Venkman, open NN 7+ and go to Venkman development page.

http://www.hacksrus.com/~ginda/venkman/

Click one of the links to install Venkman. This displays a screen similar to that shown in Figure 10-25.

Figure 10-25

Click Install and Venkman will be installed automatically. When it has been downloaded, we'll see the message shown in Figure 10-26.

Figure 10-26

We then need to click OK, close the browser, and reopen it. If we now look under the Tools ® Web Development menu we will see that an extra menu option has appeared. (See Figure 10-27.)

Figure 10-27

Choosing JavaScript debugger will open up Venkman, as shown in Figure 10-28.

Figure 10-28

The important first step is to open up Venkman from Navigator's Tools ® Web Development ® JavaScript Debugger menu. Then we can load the page or frameset that we wish to debug into Navigator. Leave Venkman open, switch to Navigator, and load the debug_timestable2.htm file we created earlier. As soon as it's loaded the page runs and comes to a stop on the debugger command and highlights where it has stopped, just as in the IE debugger. (See Figure 10-29.)

Figure 10-29

Although the layout and icons are different from those in IE's debugger, the concepts are the same, as are the sorts of things we can do. In Figure 10-29, the black background of the interactive window at the bottom-right corner is basically the same as the IE debugger's command window. In the long text box below it we can enter JavaScript code just as with the IE debugger. If we enter timesTable into the text box and press Enter, it will tell us the value contained in the timesTable variable, which because it hasn't yet been given, is currently void.

Click the Step Into icon on the debugger's toolbar and the code goes to the next line. The step over, step into, and step out commands work in a very similar way as they did in the IE debugger, but there are some differences. For example, the for loop head is just one step with Venkman whereas the MS debugger steps to the initialization first and then to the condition. Also, while the MS debugger runs over variable declarations, Venkman doesn't.

Keep stepping until we are in the writeTimesTable() function, as shown in Figure 10-30.

Figure 10-30

Notice that the window on the right-hand side in the middle, named Local Variables, has changed. It now shows under scope the variables within the scope of this function. In this function that's the counter, timesTable, and writeString variables. The current values of each variable are also shown, void in the case of variables yet to be assigned a value.

In the bottom-left corner are the Breakpoints and Call Stack windows. Currently it's just displaying the call stack but by clicking the breakpoint tab under the window we can switch to the breakpoint window and switch back with the call stack tab. Click the call stack tab to show the current state of the call stack, as shown in Figure 10-31.

Figure 10-31

As Figure 10-31 shows, there are two items in the call stack: the writeTimesTable() function call and the code that called it.

To set a breakpoint, we click the gray area in the source code window on the line where we want to set a breakpoint. (See Figure 10-32.)

Figure 10-32

In Figure 10-32, I clicked the gray area on the writeString = counter..... line, and the gray area has turned red with the letter B inside it to show it's a breakpoint. Also, the breakpoint has been listed in the Breakpoint window at the bottom-left of the screen. If we click the breakpoint again it will turn orange with the letter F to indicate this is a future break point. Clicking a third time removes the breakpoint. Alternatively, we could right-click the breakpoint listed in the breakpoint window and clear it there or indeed clear all breakpoints. Note that a future breakpoint is a breakpoint that is not set for this execution of the code but will be set next time the page is executed, for example, if we reload the page.

The final window we will mention is the File window, situated in Figure 10-32 in the top left corner. If we click the line, Navigator Window, it will open up a tree of currently loaded documents. In our case there is just one document, but there can be more than one if, for example, a frameset is loaded. This is the equivalent of the IE debugger's running documents window.

The Venkman debugger is a little more sophisticated than the basic IE debugger, and it's worth reading the full and quite extensive documentation on the Venkman home page for details.

The JavaScript Console

Ideally the Venkman JavaScript debugger is the tool of choice for Netscape debugging. However if we need to debug code running in Netscape browsers pre-version 7, our best option is the JavaScript console, available in NN 4.06+. We saw this earlier in Chapter 2, where we saw that it enables us to see any errors in code loaded into the Netscape browser. We changed the prefs.js file to cause the console to automatically open on an error for NN 4.06+ (not including NN 6 or 7).

However, the console also allows us to evaluate JavaScript statements interactively by typing code into a text box in the console. Note that currently NN 6 does have the console, but there is no facility to enter JavaScript code.

To access the JavaScript console on any NN 4.06+ browser (except NN 6 or 7), you can type javascript: into the address bar, as shown in Figure 10-33, and press Enter.

Figure 10-33

For NN 4.06+ browsers, the console that opens will be something like that shown in Figure 10-34.

Figure 10-34

If we're using NN 6 or 7, we'll need to select Tools ® JavaScript Console from the Tasks menu, after which we'll see a screen like the one in Figure 10-35.

Figure 10-35

Note that we've opened the console while the browser contained an empty page, in particular a page without errors, the main console screen is blank. Let's create a simple page with an error so that we can see what the console displays.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<body>
<script language=JavaScript type="text/javascript">
var myAge = 99;
myAge = myAge -/ 100;
document.write(myAge);
</script>
</body>
</html>

Save this as NN_ConsoleTest.htm and load it into a Netscape 4.06+ browser.

If our NN browser preferences are set to display errors in the console automatically (see Chapter 2), the console will appear as soon as the page is loaded. If not, open the console as described previously. The console will appear and display the error message shown in Figure 10-36.

Figure 10-36

The console not only displays the error message, but also gives us an indication of where it thinks the error occurred. Note that sometimes this can be misleading; although the error actually occurred at that position, we may need to rectify it by changing code elsewhere. For example, a missing curly brace marking a code block may not produce an error at the position at which the curly brace should have been. With Netscape 7.1 or later you can even click the file URL in the JavaScript console, and a source listing is opened that highlights the line where the error was found.

You can use the JavaScript typein text box to test comparison operators and perform math operations. To evaluate an expression, simply open the console and type the expression into the javascript typein text box and press Enter. The results are displayed in the upper frame.

For example, we could evaluate the following expression:

alert("hello world");

This displays an alert dialog box.

10-2;

The dialog box displays 8 in the upper frame as follows:

var high=100; var low=45;

And this creates two variables that display 55 in the upper frame as follows:

high-low;

However, while the console is very useful for viewing page errors and interactively evaluating JavaScript code, it will not allow us to interact with any of the code in the page or with the BOM in any meaningful way. For example, with the test page we used previously, we had a variable myAge. Whether we opened the console ourselves or it was opened automatically by the error, there is no way of checking the value of myAge or accessing the window or document object of that page or any code inside it. For example, type the following into the text box and press Enter:

alert(myAge);

We just get the following message:

JavaScript Error: [unknown origin]:
myAge is not defined.

This limits the console's use in debugging.