FireBug

I definitely saved the best for last with this extension. FireBug is one of the premier debugging tools for Ajax, JavaScript, CSS, and XHTML applications. It supports error and warning descriptions for JavaScript and CSS. This tool not only provides extremely accurate feedback about errorssuch as what went wrong, what line it happened on, and what file it happened init also opens the file within the Debugger tab and highlights the line of code that is throwing the error. Now that is accuracy! But it gets even better: Not only does it provide the error, it allows us to set breakpoints in the code from the Debugger panel and rerun the page to stop the page when that line of code is reached. I never dreamed of such things with JavaScript! Most relevant to our Ajax applications is the fact that it also allows us to spy on XHRs and returns just enough detail about them to eliminate the need for the responseText in an alert approach.

Installing FireBug

In order to install the extension, we first need to have the Firefox browser, which can be downloaded from http://www.mozilla.com/firefox/. After we have the browser installed, we can get the FireBug extension at http://www.joehewitt.com/software/firebug/. Joe Hewitt has built a very minimal and easy-to-use debugging tool that can accomplish a lot of debugging techniques. In order to use the extension after it is installed, we need to either click on the check mark on the bottom-right corner of the browser window or go to Tools, FireBug and choose an option from the extension's list. Figure 8.7 shows a screenshot of the options we get after the extension has been opened.

Figure 8.7. These are the options that are available for displaying errors, warnings, and XHRs.

The Command Line

The command line enables us to write arguments against the page with JavaScript and receive responses, which would typically display in an alert (that is, if we were alert debugging). This step eliminates the need to go back and forth between our development tool of choice, check out the file from the server, and write the code we want to test, by either adding it to an alert or writing it to the document, and then re-upload the file and test. These four steps are eliminated with a simple command line, which is built in to the bottom of the tool. Take a look at Figure 8.8 for a screenshot of the command line in action.

Figure 8.8. The command-line input and results provide a quick way to test JavaScript.

The command line enables us to do much more than write simple strings to the console. Writing a reference to an object creates a hyperlink in the FireBug console. When we click an object hyperlink in the console, we are taken to the Inspector, which displays the selected object in the appropriate tab. For example, the sample application has a div element named email in the index, which contains all the components in the application. If we wanted to test the object hyperlinking, we could type document.getElementById('email'); into the command line and view the results. Figure 8.9 shows an example of the hyperlink that appears in the console when we write this code.

Figure 8.9. Targeting HTML elements via the command-line.

Table 8.1 shows a list of built-in functions that can be invoked from the command line. These functions are useful shorthand approaches to receiving command-line responses.

Table 8.1. FireBug's Built-in Command-Line Functions
Functions	Definitions
`$("id")`	Represents the following function: `document.getElementById().`
`$$("css")`	Returns an array of elements that match a CSS selector.
`$x("xpath")`	Returns an array of elements that match an XPath selector.
`$0`	Variable containing the most recently inspected object.
`$1`	Variable containing the next most recently inspected object.
`$n(5)`	Returns the nth most recently inspected object.
`inspect(object)`	Displays the specified object in the Inspector.
`dir(object)`	Returns an array of property names from an object.
`clear()`	Clears the console.

Logging Messages in the Console

The console.log method is a sophisticated replacement for alert debugging. This method takes two parameters: The first is anything that you want to display in the console, and the second is an optional parameter that selects a tab in the Inspector based on the value specified. This would be the perfect solution to displaying the responseText that we were debugging earlier in the chapter. Using the console.log method is very simple:

console.log(param, 'optional tab');

This obviously does not work in other browsers because FireBug does not have compatible versions, so when deploying the live version of an application that uses them, make sure that we remove them.

The basic logging method is not just an alert-debugging replacement. As we learned with the command line, writing a reference to an object creates a hyperlink in the FireBug console. When we click an object hyperlink in the console, we are taken to the Inspector, which displays the selected object in the appropriate tab. This also applies to passing an object reference as a parameter to the console.log method. This suddenly makes the console.log method a lot more powerful and sets it far above other debugging methods. As if that wasn't enough there are also different levels of logging messages according to severity.

Levels of Logging

In order to log errors, warnings, debug messages or other random information we can use the different levels of logging that exist in FireBug. They not only visually separate different types of messages in the console, they also provide a link in the console to the exact line number in the source code where they reside. This can be extremely useful during development phases by eliminating excessive debugging time. In order to use these different methods in your JavaScript you would write them as follows:

console.debug("message" [,objects]); console.info("message" [,objects]); console.warn("message" [,objects]); console.error("message" [,objects]);

Inspecting Elements

FireBug provides the capability to inspect elements within a page called Instant Inspecting. I believe this is the most useful approach to debugging that I have come across. Instant Inspecting can be accessed by either going to Tools, FireBug, Inspect Element or by clicking the check mark at the bottom-right corner of the browser and choosing the Inspect button from the top-left menu, next to the Clear button. After we have activated the Inspector, we can hover the mouse over the page to inspect the elements within the page. As we hover over them, we see the structure of our page and how certain items relate to others. Figure 8.10 shows the Inspector in action as it highlights the tag in the code for the element that is currently being hovered over.

Figure 8.10. Instant Inspecting provides a different perspective on web applications.

Another unbelievably helpful feature the Inspector includes is live editing. Live editing enables us to click on a tag attribute value, such as a div id value, and change it within the editor to test the new behavior. This is another great timesaver that eliminates quite a bit of steps from the traditional debugging approach. Figure 8.11 shows an example of live editing with a div id from the sample application.

Figure 8.11. Live editing enables us to edit tag attributes during runtime to test functionality.

Inspecting events is another feature that FireBug offers, which can be used by selecting the Inspector tab and then the Events tab from the bottom of the window, and then clicking the Inspect button. After we have activated the Inspector, we can hover over the application to receive all the events within the page. As we can see in Figure 8.12, all the eventsfrom a simple mousemove to a DOMActivateare displayed within the Inspector.

Figure 8.12. Inspecting events provides vital information during runtime.

At first glance, it is obvious that the event inspecting can become fairly messy, especially with all the mousemove events. Luckily, there is a feature that allows you to filter the events you want to inspect. The search box that is located in the top-right corner of FireBug is used for this solution. Just type in the event you want to see, such as mouseover, and it will automatically filter out all other eventsvery handy.

Spying on Ajax

XHRs can be watched (or spied on) with a built-in XHR event listener in FireBug. This tool provides us with the Post or Get tab, the Response tab, and the Headers tab from a request's response. To activate the XHR spy, we must choose the Show XMLHttpRequests option from the Options drop-down in FireBug. Once activated, it will display all XHRs that are made within a web application. By default, it shows the requested URL and the method that was used to make the request. When one is selected it expands, leaving us with three options: Post or Get (based on the type of request), Response, and Headers. By clicking each of the tabs, we can view the data that was used for each. The Post or Get tab shows us the request that was made, whereas the Response tab shows the response from the server, such as XML, JSON, and so on. The Headers tab displays the headers from the server that were received with the response. No more writing alerts on the request headers! The Post or Get tab can be useful if we want to see the URL that is being requested and the parameters that are being sent in the query string. Figure 8.13 shows a request with a couple of parameters as a query string.

Figure 8.13. Viewing an XHR.

In this case, the Response tab shows the XML that is being returned from the server. See Figure 8.14 to get an idea of how this looks.

Figure 8.14. Viewing the response from the XHR.

As Figure 8.15 shows, the Headers tab displays the headers that were sent by the server where the sample is residing.