Debuggers - Java Script

Programmers used to developing in languages such as C, C++, Java, and Perl know that debugging is an important part of the development process. These developers rely heavily on debuggers for such programming languages to aid in tracking down errors in their code.Most languages offer some type of debugger, from simple command line programs to exhaustive GUI layouts. Although JavaScript itself doesn’t have a debugger, both Internet Explorer and Mozilla have debuggers available.

Microsoft Script Debugger

The Microsoft Script Debugger is a free utility available from Microsoft’s Web site. The results list comes up with Script Debugger for Windows NT, 2000, XP.Click that link and click the Download button. Run the installation program and then restart Internet Explorer.

Notice a new menu item that appears under the View menu called Script Debugger. This provides options for running the debugger.


You can run the Microsoft Script Debugger in a number of ways. First, you can open it directly by selecting View

  1. Script Debugger - Open, which opens the debugger with no information loaded.
  2. The second method is to select View
  3. Script Debugger - Break at Next Statement,which opens the debugger before the next JavaScript command on the page is executed.

The debugger is brought up with the file that contains the executing JavaScript.Using this method, the line about to be run is highlighted in yellow.Lastly, you can use the JavaScript debugger command to bring up the debugger from anywhere in your code:

When the code encounters the debugger command, code execution is halted and the debugger is opened (making it very similar to the Break At Next Statement option).

The Window

The Microsoft Script Debugger is actually made up of a single window with three smaller utility windows.

The Window

The first utility window is labeled Running Documents. This window displays all instances of Internet Explorer that are currently running,as well as all the documents that are loaded into each instance. By clicking on the plus sign next to an icon, you can see not only the HTML file that is loaded, but also all its associated JavaScript files. You can then bring up the source of any file by double-clicking on it in the window.

The second utility window is labeled Call Stack and, as you might assume,this displays the call stack up to the current breakpoint in the code. Double-clicking on an entry in the Call Stack window brings up the source code for the function.

The last utility window is labeled Command Window and is very similar to the Immediate window in Visual Studio. Here, you can type in JavaScript commands in the context of the executed code to check the values of variables.To do this, simply type the variable whose value you want to see followed by a semicolon. For instance,to get the URL of the window,type:


When you hit the Enter key, the line of code is evaluated and the value displayed.

Breakpoints and stepping

The Debug toolbar contains all the options you need to step through JavaScript code and set breakpoints.

Breakpoints and stepping

To set a breakpoint in your code,load the file into Internet Explorer and then open the debugger. Find the file you want to debug in the Running Documents window and double-click it. Then, go to the line of code you want to stop on and click the Set Breakpoint button (the white hand) in the toolbar. The line is then highlighted in yellow, and a yellow arrow is placed in the margin. Then, go back and reload the page in Internet Explorer and run the command; execution stops at the specified point and the debugger takes over.

At that point, you can do several things. If you want to step through the code, you can use the Step Into (which executes the code line by line, stopping after each one), Step Over (which doesn’t follow code execution into functions),and Step Out (which moves execution outside of the function to the place where the function was called).

If you want to continue normal execution of the code until the next breakpoint,click the Run button; if you want to stop debugging altogether, click the Stop Debugging button to prevent any further stoppage in the code’s execution.

Venkman – Mozilla’s debugger

The Mozilla debugger, Venkman(named after the character Peter Venkman of theGhostbusters movies), is a free utility for Mozilla-based browsers (including Firefox). At this address, you find a list of all the Venkman builds.Click the Install link next to the latest version. You are prompted to continue the installation because Venkman is an unsigned Mozilla plugin.Click Install Now. Restart the browser and you notice a new entry under the Tools ➪ Web Development menu.


To run Venkman,click Tools ➪ Web Development ➪ JavaScript Debugger to manually open the window. When you do so,the Venkman window automatically loads all the files containing JavaScript into the debugger.

You can also use the debugger command in your code. It works with Microsoft’s Script Debugger. Any time you include the debugger command, the debugger opens up at that line of code and stops execution.

Unlike Internet Explorer, Mozilla never asks you if you’d like to debug an error.

The Window

The Venkman window is much more complicated than the Microsoft Script Debugger, but also a lot more powerful.

The window is made up of several smaller windows (or views) containing various information about the scripts you are inspecting. Each view is made up of several common components, as illustrated in figure.

The Window

The Window

Each view consists of the following:

  1. A small square in the upper-left corner. Clicking this square causes the view to dock or undock from the main window. You can also drag this square into another view’s square to combine views into one tabbed view.
  2. A title for the view
  3. An X in the upper-right corner, used to close the view.(You can always bring the view back by choosing View ➪ Show/Hide and then the appropriate view.)
  4. A content area, displaying a list or other information about the script
  5. An optional tabset. If more than one view exists in the same area, the debugger adds a tabset to allow you to switch back and forth between the views.

The entire interface is completely configurable to allow you to rearrange, resize, and otherwise manipulate the Venkman window to best suite your needs.

Eight views are available in Venkman, and each is just as powerful as the last:

  1. Loaded Scripts— Displays the files that contain JavaScript, whether they are HTML or external JavaScript files. Each file can then be expanded to show the functions contained within, complete with the function name and the line on which the function begins.
  2. Open Windows — Displays all browser windows (and tabs) Mozilla has open. Under each window is the HTML file that is loaded, and under that is a list of JavaScript files. You can shift the focus of the debugger to a particular window by right-clicking on a given file and selecting Set As Evaluation Object.
  3. Local Variables — When a breakpoint is encountered, this view fills up with all the variables available in the scope of the executing code. If a variable contains an object, you can expand the variable name to see all the object’s properties as well. To change a value of a variable while stopped at a breakpoint, just double-click the variable name and enter a new value.
  4. Watches — Displays a list of watches for the debugger session. Watches work by watching variables to see when their values change. When a value changes, it’s updated in the Watches view (Watches will be discussed further later on).
  5. Breakpoints — Displays a list of breakpoints registered for the debugger session.
  6. Call Stack — When a breakpoint is encountered, this view shows the call stack (the sequence of function calls that led to the breakpoint).
  7. Source Code — Displays the source code for any file containing JavaScript code.
  8. Interactive — A traditional-style command line interface to the debugger. In this view, you can control nearly every part of the debugger with text commands.

The Loaded Scripts pane

By default,the Loaded Scripts pane is displayed in the upper-left corner of the debugger window. It displays the location of the scripts currently loaded into the debugger.This includes any scripts contained in HTML pages as well as external JavaScript files.

Under each file (JavaScript or HTML) is a list of functions that exist within that file. In Figure the example using the throw operator is loaded, so you can see the function addTwoNumbers() as well as he line number that the function begins on within the file. If you double-click on the file (or right-click and select Find File),the source code of the file is displayed in the Source Code pane. If you double-click on a function (or right-click and select Find Function),that function becomes highlighted in the source code pane.

The Loaded Scripts pane

For each file in the Loaded Scripts pane, you can determine whether the script contained within it should be debugged or not.Just right-click on the file and select File Options. A submenu appears giving you complete control over debugging and profiling.

The Loaded Scripts pane

If you don’t want to debug any code in the file,click Don’t Debug Contained Functions(by default, all functions are debugged). This menu also allows you to prevent debugging of eval() or timeout code by selecting Don’t Debug Eval/Timeout.

By default,Venkman tries to show only the files you have loaded into the browser; however,it is capable of loading all files that the browser loaded behind the scenes in addition to your own. You see all the loaded browser files by unchecking Exclude Browser Files on the context menu. Also by default, the pane only shows one instance of each file that is loaded; you can override this by unchecking Exclude Duplicates on the context menu.

Each function in the Loaded Scripts pane also has a certain level of control. By right-clicking on the function, a context menu similar to that of the file is presented. Under Function Options, you can click Don’t Debug to force the debugger to ignore that one function instead of the entire file.This gives you an optimal level of control over the debugging process.


Among the several ways to set up breakpoints in Venkman,the fastest and easiest way is to double-click on the file containing the script to debug.When that code shows up in the Source Code view, scroll down to the line on which you want to set the breakpoint on and click the left margin next to the line (a dash is next to any line where a breakpoint can be set).You see a B,meaning that a hard breakpointhas been set, or an F, meaning that the debugger could only set a future breakpoint .A future breakpoint is created when the script has already been unloaded from memory, but it becomes a hard breakpoint the next time the script is loaded (if you reload the browser,for example).


You can always create a future breakpoint by double-clicking in the left margin instead of single clicking, but you cannot force a hard breakpoint if, after one click,a future breakpoint is set.

The second way to set a breakpoint or future breakpoint is to use the command-line interface and the /break command (to set a hard breakpoint) or /fbreak command (to set a future breakpoint). Both commands take two arguments: the filename to set the breakpoint in and the line number to set the breakpoint on. For example:

/break ThrowExample.htm 7

This command sets a breakpoint on line 7 in the file matching ThrowExample.htm. For the filename, you don’t need to type in the full path or even the full filename. Just a few characters are needed to uniquely identify the file among all the files that are loaded into Venkman. Just the first few letters of the filename are usually enough:

/break Thr 7

After a breakpoint has been created (using either method), it is stored in the Breakpoints view under the filename.Hard and future breakpoints are stored separately, so you may see two different entries for the same file. Only hard breakpoints can be viewed by function name and line; future breakpoints are listed only as filename and line number.

Break points

You also have many options to clear a breakpoint. First, you can click on the B or F in the left margin until it turns back to a dash. You can also right-click on the Breakpoints view to call up a context menu where you can select whether to clear a hard breakpoint,a future breakpoint, all hard breakpoints, or all future breakpoints.

The last method is to use the command line interface again and use the /clear command (to clear hard breakpoints) or the /fclear command (to clear future breakpoints).These commands accept the same arguments as /break and /fbreak: the filename and the line number to clear. Once again, the full filename isn’t necessary, so the following two lines accomplish the same thing:

You can clear all hard breakpoints using the /clear-all command and all future breakpoints using the /fclear-all command.

Stepping through the code

As with breakpoints,you have numerous ways to step through your source code.The simplest way is to use the debug toolbar, which is prominently displayed at the top of the Venkman window.

Stepping through the code

The debug toolbar is made up of five buttons: Stop, Continue, Step Over, Step Into, and Step Out.The Stop button stops the currently active script without executing any further lines of code.If no code is being executed, three white dots appear over the Stop button to indicate that the debugger is not currently running any code. The Continue button resumes executing the script and continues until the natural end of the script or a breakpoint is encountered. The last three buttons are standard Step Over, Step Into, and Step Out commands.

All these actions can also be performed in the Interactive view by using the commands in the following table.

Interactive view by using the commands

When code execution is stopped on a particular line, that line is highlighted in yellow in the Source Code view.Additionally, the function containing that line is displayed with a yellow arrow in the Call Stack view .

Call Stack view

The Call Stack view always has a generic __toplevel__ item to represent the global scope from which the first function was called.


One of the unique features of Venkman is its capability to set up variable watches. Watches literally watch variables for changes in their values and display them in the Watches view.

To add watches, you can select a variable in the Local Variables view, right-click, and select Add Watch Expression.You can also use the /watch-expr command in the Interactive view to do the same thing:

/watch-expr variable_name

Adding a watch adds a variable into the Watches view. The Watches view behaves in the exact same way as the Local Variables view, displaying the value of each variable when available and enumerating all properties of each object.


One of the unique features of Venkman is its profiling capability. If you turn on profiling, Venkman begins keeping track of each function, how many times it’s called, and how long each call takes.

You can turn profiling on and off by clicking the Profile button on the toolbar. A green checkmark appears on the Profile button when Venkman is profiling; no checkmark appears when it is not profiling.

After Venkman is in profiling mode, run your script. When you are satisfied with your tests, select Profile ➪ Save Profile Data As. You are presented with a Save File dialog where you can save the profile data to view later.

By default, the dialog suggests you save the file in HTML format. This is a bug; you should save the file as plain text.

When you profile your script,each function gets a section in the file that looks like this:

Each section begins with the location of the file containing the function and is followed by each function contained in the file. Each function is displayed with the following:

  1. The lines it appears on
  2. The total number of calls to the function and the maximum recursion level reached (identified by max recurse)
  3. The total amount of time (in milliseconds) it took to run the function along with the minimum time for a call, the maximum time for a call, and the average time for a call

This information is incredibly useful for detecting bottlenecks in your code.

You can also determine which functions are profiled.To set an entire file so that it won’t be profiled, right-click on the file in the Loaded Scripts view and select File Options ➪ Don’t Profile Contained Functions. If you want to disable profiling for a single function, right-click on the function in the Loaded Scripts view and select Function Options ➪ Don’t Profile.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Java Script Topics