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 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.
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
console.debug("message" [,objects]); console.info("message" [,objects]); console.warn("message" [,objects]); console.error("message" [,objects]);
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.
Figure 8.15. Viewing the headers that were sent by the server with the response to the XHR.