AJAX Debugging Overview

Unfortunately, today’s tools for client-side debugging and tracing aren’t as evolved as their server-side counterparts. For example, things such as capturing ongoing communication traffic between the client and the server, or client-side debugging, aren’t usually supported by today’s IDEs (Integrated Development Environments) such as Microsoft Visual Studio 2005. The next version of Visual Studio (code-named Orcas at the time of writing) promises a lot of improvements in this area:

• Improved IntelliSense technology with support for JavaScript code, which provides coding hints based on specially-formatted comments in the code
• Breakpoints in inline JavaScript code

These are only the most important new coming features; there are others as well. For more information we suggest that you browse and keep an eye on Scott Guthrie’s blog at http://weblogs.asp.net/scottgu/, the JScript blog at http://blogs.msdn.com/jscript/, Bertrand Le Roy’s blog at http://weblogs.asp.net/bleroy/.

Until this new edition of Visual Studio is released, we can rely on third-party tools that can do a very good job at helping us develop our AJAX applications. You’ll find a number of tools for Internet Explorer and Mozilla Firefox for this purpose.

Debugging and Tracing with Microsoft AJAX Library

The common practices for debugging JavaScript code are:

• Putting alert messages throughout the code to get notified about the values of the variables
• Logging tracing messages in a <div> element

While the first option is straightforward, the second option offers a centralized place for storing different messages and could be considered more appropriate. Nevertheless both options can come in quite handy depending on the circumstances.

Microsoft AJAX Library offers the Sys.Debug object that has a series of methods that you can use for debugging and tracing. The diagram of this class is presented in figure below.

The Debug class

As we can easily see in the diagram, Sys.Debug offers the most common features that we can find also in other languages: assert(), trace(), traceDump(), fail(), and clearTrace().

assert(), trace(), and fail() automatically send the messages to the debugging console of the browser. To see the messages in IE you need to have the Web Development Helper, and for Firefox you need the Firebug plugin. Both of these tools are presented later in this article. Internally assert() calls fail() if the expression evaluates to false. fail() simply logs the message passed in by assert to the debugging console.

trace() offers an interesting feature beside logging to the debugging console: it offers the possibility to log the trace message in a <textarea> element with the ID TraceConsole. If such an element is found, trace() will log this message in this element too.

The clearTrace() function simply clears the TraceConsole element, if found.

The traceDump() function traces all the information about an object including its properties. Internally this function uses the trace() function so that we can have the information logged in the browser’s debugging console, and in the TraceConsole element (if it exists).

MicrosoftAjax.debug.js

You might have wondered why the Microsoft AJAX Library comes with both release and debug version of the JavaScript file. The major features of the debug version of the library files are: 

• The script is nicely formatted.
• The names of variables are not obfuscated.
• The script contains code comments.
• Some of the functions have the optional summary data that will be used by Visual Studio “Orcas” for code auto-completion.
• The script outputs debugging-friendly information.
• Parameters are validated.

Once the development stage is finished, you can switch your application to the release version of the script (MicrosoftAjax.js), which is smaller and doesn’t contain the debugging features presented above.

Perhaps the most interesting features of the debug version are the last two: debugging-friendly information and parameter validation.

Anonymous Functions vs. Pseudo-Named Functions

We will explain these two concepts by taking a look at how different functions are defined in the debug and release version of the library. The debug version of the library contains:

function Sys$_Debug$assert(condition, message, displayCaller) {
   ...
}

Sys._Debug.prototype = {
  assert: Sys$_Debug$assert,
  ...
}

and:

String.format = function String$format(format, args) {...}

In the release version of the library we have:

Sys._Debug.prototype = {
  assert: function(c, a, b) {
  ...
}

and:

String.format = function() {...}

In the release version, we have methods that are anonymous functions. This means that within a debugger stack trace the method name will read JScript anonymous function. This is not very useful for debugging purposes, is it?

Call Stack showing anonymous functions

However, the debug version of the library uses the dollar-syntax to provide alias names for our functions: String$format for String.format and Sys$Debug$assert for Sys.Debug.assert. When using the debug version of the file, the stack trace would look like:

Call Stack showing named functions

We can still notice some anonymous functions as they are the result of creating callback or delegate functions. The example shows two different ways of coding: 

• In the debug version, the function is declared outside the prototype and then referenced in the prototype declaration.
• In the release version, the declaration is done directly where the function is declared (outside or inside the prototype).

Parameters Validation

Another interesting feature that has not been documented in the Microsoft AJAX Library documentation is that of parameters validation.

Type safety is one of the typical problems when it comes to using JavaScript. Although the dynamic type features are really useful, sometimes we might really want to make sure that a parameter or object is of a certain type. To check the data type of an object, you can try converting the object to the desired type, or using the methods defined by Type. Fortunately the Microsoft AJAX Library has a function that does the dirty work for us: Function._validateParams(). The class diagram in figure below shows the _validateParameter() and _validateParams() methods of the Function class.

The Function class

The Function._validateParams() function, even if it is declared as private (by convention, using the leading underscore), can be used by our scripts as it is used throughout the debug version of the Microsoft AJAX Library. Here’s an example of using this function:

function Sys$_Debug$fail(message) {
/// <param name="message" type="String" mayBeNull="true"></param>
   var e = Function._validateParams(arguments, 
         [ {name: "message", type: String, mayBeNull: true} ]);
   if (e) throw e;

This shows how the parameter for the fail() function is validated as a String. We can also see the additional code comments inside the function, which are meant to be used by the IntelliSense feature in Visual Studio “Orcas” to check for the correctness of the parameter types.

While the first parameter of _validateParams() represents an array of parameters to be checked, the second parameter is an array of JSON objects describing the validation rules for the array of parameters. Each JSON object contains a validation rule for a parameter. The JSON object is a dictionary of keys and values. The list of keys that can be used is described in the table that follows.

The function returns an error message if the parameters don’t validate and the error is typically thrown like this:

if (e) throw e;

This exception could be caught and the appropriate measures taken programmatically. If the exception is not caught, the error will pop up in the debugging console of the browser.

A practical tutorial to using Microsoft AJAX to enhance the user experience of your ASP.NET web applications covering the most up to date versions of the AJAX tools. For more information, please visit: www.PacktPub.com/ajax-csharp-essentials/book

Debugging in Internet Explorer

By default, JavaScript errors are ignored by Internet Explorer. In order to be able to debug in Internet Explorer, you need to: 

1. Start Internet Explorer and go to Tools | Internet Options | Advanced and clear the Disable script debugging (Internet Explorer)   and Disable script debugging (Other) checkboxes. If you want a pop-up window to be displayed for each error, you need to check the Display a notification about every script error checkbox, as shown:

Enabling debugging in Internet Explorer 

2. Open the solution you want to debug in Visual Studio. 
3. Execute the project. 
4. After the Internet Explorer window opens, go back to Visual Studio. 
5. Open the script explorer by going to Debug | Windows | Script Explorer. The script explorer will list the available script files that can be debugged

Using the IE script explorer 

6. Double-clicking a file in the script explorer will open it in the editor. There you can place breakpoints inside JavaScript files, and the feature will work just as it does when debugging server-side code.

Debugging JavaScript code using Visual Studio

Alternatively, if you have Visual Studio, you can attach the debugger to an existing the Internet Explorer process by selecting Debug | Attach to Process, and then choosing the Internet Explorer process (iexplore.exe).

If Internet Explorer is configured for debugging and a script error is encountered in the browser while no debugger is attached, you’re prompted to choose one of the available debuggers: 

• Visual Studio and Visual Web Developer 2005
• Microsoft Script Debugger (downloadable from Microsoft’s website)
• Microsoft Script Editor (ships with Microsoft Office)

For more about debugging web applications in Visual Studio, see these links: 

• http://msdn2.microsoft.com/en-us/library/sc65sadd(VS.80).aspx
• http://www.developerfusion.co.uk/show/5918/
• http://msdn2.microsoft.com/en-us/library/k2h50zzs(VS.80).aspx

Web Development Helper

Web Development Helper is a great tool developed by Nikhil Kothari and should be used by every developer who needs the following development features: 

• HTTP(S) traffic monitoring
• DOM inspector
• Script errors and immediate window

Web Development Helper can be downloaded from: 
http://www.nikhilk.net/Project.WebDevHelper.aspx.

For more documentation about this tool, check the following links: 

• http://projects.nikhilk.net/WebDevHelper/Readme.pdf
• http://www.nikhilk.net/WebDevHelperDebuggingTools.aspx
• http://weblogs.asp.net/scottgu/archive/2006/11/13/Nikhil_2700_s-WebDevHelper-Utility-and-ASP.NET-AJAX-Support.aspx

When it comes to debugging, the tool offers nice features such as showing the trace, catching run-time errors, and showing the full call stack (including script URL, line number, and line of code). The Script Console window allows entering custom script that is executed within the document context.

Internet Explorer Developer Toolbar

Microsoft offers the Internet Explorer Developer toolbar as an option for exploring web pages. It is especially useful for working with the page’s DOM element, CSS styles, cookies, etc. It can be downloaded Microsoft’s web site.After it installs, you open it through Tools | Toolbars | Explorer Bar | IE Developer Toolbar.

Internet Explorer Developer Toolbar in action

It is worth mentioning that it doesn’t compete with Nikhil’s tool, but it’s more like a complementary tool as it doesn’t offer JavaScript debugging capabilities or any of the other main features by Web Development Helper.

Other tools

There are other other tools that are worth mentioning and that you should keep an eye on: 

• Damian Meher’s TraceJS   is a tool that logs every line of script executed in Internet Explorer. Find it at http://damianblog.com/2006/11/23/tracejs/.
• Julien Couvreur’s XMLHttpRequest debugging bookmarklet. See http://blog.monstuff.com/archives/000291.html and http://weblogs.asp.net/bleroy/archive/2006/05/15/446532.aspx.

Debugging in Firefox

With the increasing number of users of Firefox, the number of tools used for web development has grown as well.

First of all, Firefox offers an Error Console accessible from the Tools menu, where all the JavaScript errors, warnings, and messages are logged. It also has a built-in script evaluator within the document context, and the DOM Inspector tool, which can be selected at installation time, so we can say that the features packaged into Firefox are quite advanced in comparison with the default features of Internet Explorer. Below figure shows the Error Console signalling a typo in our code.

The Error Console in Firefox

Firebug

Firebug (http://www.getfirebug.com/) is a Firefox plugin that offers almost anything a web developer could want from a debugging tool: 

• Debugging and profiling   script
• Monitoring HTTP traffic
• Examining HTTP headers
• Inspecting and editing the DOM
• Inspecting and editing CSS
• Quick search for filtering errors and messages

Delivering such a powerful set of tools in one free product makes Firebug the perfect choice for debugging applications in Firefox. Following figure shows Firebug in action.

Debugging using Firebug

Venkman JavaScript Debugger

The Venkman JavaScript debugger (http://www.mozilla.org/projects/venkman/) is a powerful tool for debugging in Mozilla-based browsers (Firefox, Netscape, and Seamonkey).

Like Firebug, Venkman JavaScript Debugger offers debugging and profiling, full call stack, breakpoints, local variables, and watches, all within an interface that is very similar to Visual Studio. See this tool in action in figure below.

Debugging using Venkman JavaScript Debugger

You can find a few excellent online articles for using Venkman JavaScript Debugger: 

• http://www.svendtofte.com/code/learning_venkman/
• http://www.hacksrus.com/~ginda/venkman/
• http://www.webreference.com/programming/javascript/venkman/

Web Developer

Similar to what Firebug and Internet Explorer Developer Toolbar offer, Web Developer plugin (https://addons.mozilla.org/en-US/firefox/addon/60), provides a most comprehensive set of tools for: 

• DOM information and inspection
• Outlining different elements (frames, headings, tables, links, etc.)
• HTTP headers, JavaScript, images information
• Cookies
• CSS
• Page validation (CSS, HTML, WAI, links, Section 508)

All in all, this extension is a very good companion for developing websites. The homepage for this extension and some documentation can be found at http://chrispederick.com/work/webdeveloper/.

Fiddler

When it comes to inspecting and tampering with the HTTP(S) traffic from our computer and the Internet, the most popular tool you can find is Fiddler. This is a freeware tool that allows inspecting all HTTP and HTTPS traffic and tampering it, setting breakpoints, making it an ideal candidate for debugging applications.

It also offers an event-based subscription system offering the capability to easily extend it. Install Fiddler from http://www.fiddler2.com/Fiddler2/. You can find a quick introduction to Fiddler on MSDN, and in the following resources: 

• Fiddler tutorial http://www.developer.com/lang/jscript/article.php/3631066
• Fiddler2 demonstration videos http://www.fiddler2.com/fiddler/help/video/default.asp
• Fiddler2 extensions development http://www.fiddlertool.com/fiddler2/extensions.asp
• Fiddler2 user interface http://www.fiddler2.com/Fiddler/help/ui.asp

Testing

There are a lot of testing tools available today, but only few of them allow for automatic testing of AJAX applications. Dan Wahlin has put together a list of automated testing and debugging tools on his weblog at http://weblogs.asp.net/dwahlin/ on 2007/02/16/.

In his article we can find some of the tools that we presented so far, and also a comprehensive list of tools that we can use for automatic testing.

A less documented feature of Fiddler is that it can generate Visual Studio WebTest files that can be using in Visual Studio. Why is this necessary? Visual Studio doesn’t record AJAX requests based on XMLHttpRequest, but only full postbacks.

In order to create a Visual Studio WebTest file, you need to follow these steps: 

• Open Fiddler.
• Start capturing   the traffic by pressing F12 or by selecting File | Capture Traffic.
• Browse the AJAX application and Fiddler will register the requests.
• After having finished the steps save the session by going to File| Save | Session(s) | as Visual Studio Web Test.
• Now you can import the generated file in Visual Studio and use it for automatic testing.

Summary

Debugging and testing are quite complex tasks and they could be the subject of an entire book. The goal of this article was to introduce the common tools and techniques for debugging and also to offer a glimpse into the world of automated testing tools for AJAX applications. With the continuous growth of AJAX applications, the need for more complex tools will generate new products so that it’s worth keeping an eye on what’s new in this domain.