10 Ways to Debug JavaScript in IE 8
I know, I know use FireBug and FireFox. I hear it all the time. I say meh, everyone does that. As I wrote last year, in IE 8 press F12 and Bazinga!!! You get the IE Developer tools. Read more about using the IE developer tools in my old post. But I show this in my CodeCamp sessions and folks are just amazed the tools are there and they work quite nicely.
Now that I spend a majority of my web development in the JavaScript layer debugging my scripts is very important. If you are working in the corporate world chances are you are targeting IE (version 8 I pray). So lets look at 10 ways to debug your JavaScript in IE 8.
Set Breakpoints
Any good debugging experience has to allow you to set a breakpoint, or designate a place in your code to stop execution and allow you to examine variables and process flow. The IE Developer tools are no different. Just like Visual Studio you can view your JavaScripts in the Script Tab.
Across the top of the tab there is a toolbar, the ‘Start Debugging’ button and the dropdown to the right are the most important items. More about the button in a moment. The dropdown is a list of scripts and markup pages, i.e. resources that can contain JavaScript. Clicking the dropdown list reveals a list of possible scripts, selecting an item opens that script in the tab.
The script window is a viewer, not an editor, which I can understand. There are many instances where it would not have rights to edit anyway because the scripts are loaded through a web server, etc. The line number is displayed to the left, which is important to locate code to actually edit in Visual Studio later.
Setting a breakpoint is very straight forward. Place your cursor on the line you want to set a breakpoint and press F9. In the right-hand pane there are several action buttons on the right, which are basically tabs they just don’t look like it. Selecting the Breakpoint option shows a list of breakpoints. There is a checkbox to the left of each breakpoint. Unchecking the correlating checkbox disables the breakpoint. You can also delete individual or all the breakpoints as well.
To enable debugging mode the ‘Start Debugging’ button needs to be pressed. This changes the button to a ‘Stop Debugging’ button, which make sense, right? Now when you load the page, or cause script to be executed the debugger watches the execution and if it hits a breakpoint it stops execution to allow you to evaluate the code.
Just like other IDE (i.e. Visual Studio) conventions convey for stepping through code. F10 goes to the next line in scope, F11 steps into a function, etc. F5 even starts the debugger and lets you continue execution from a breakpoint. You can even set breakpoint conditionals. That is where you designate a condition where the breakpoint actually executes.
View Local Variables
Now that you have hit a breakpoint there are two things you need to do, see what variable values are and of course step through the code. Back over to the right-hand pane there is another button called ‘Locals’. Pressing this button reveals, well nothing really, until you hit a breakpoint. Once you hit a breakpoint in a script you will see all the locally scoped variables on the left and their values on the right. If a variable is an object literal you can expand it to see the values of each property. You can expand properties too if they are objects.
Add Watches Directly From Your Code
Additionally you can also add custom watches. These can be viewed by pressing the ‘Watch’ button on the toolbar. Custom watches can be added in two ways. First by selecting a variable or expression in the script, right-clicking and selecting ‘Add Watch’. The selected variable or expression is now added to the Watch window.
Add Custom Watches Directly in the Watch Tab
You can also add a watch by hand by clicking on the last row in the watch window. Here you can just start typing in the variable name or expression to watch. This is extremely useful when you are trying to see things like what a different selector references or a modification of an expression. You can also edit any watch by clicking it. Then you just start editing it as needed.
Step Through Your Code
Stepping through code is a breeze as well. F10 to step to the next line. F11 steps into a function. Be careful stepping into functions, if you step into a minified script (like the jQuery framework) you will most likely feel lost and it may be somewhat difficult to get back up to your code because the flow goes through so much framework code.
Change a Variable Value
Just like working in Visual Studio you can change the value of a variable in the watch window as you are stepping through code. You can do the same in either of the IE Developer Tools Watch windows. Simple double-click the current value and change it accordingly.
Drill Into an Object
I mentioned above you can expand an object in either of the watch windows. If a variable is an object literal you will see a + icon to its left. This indicates it can be expanded to view the child properties. One you do this you can manipulate their values and expand them as well.
Use the Console To Test Code
The console is just like the Console window you never use in Visual Studio the IE Developer tools allow you to type expressions for evaluation. You can think of this is sort of a scratch pad to try ideas out. If your script hits an unhandled exception you will also see the error messages here.
You can also use the console object in your script to echo information to the this window during the execution of your test.
Use the Console to Reveal Syntax Issues
I mentioned above if there is an unhandled exception in your script it will be logged to the console window. This is true if you have a syntax error. When the browser loads your script and there is a syntax error, think missing ; or closing } etc, you typically see a little warning icon in the bottom-left corner of the browser. Viewing the console window will tell you what the issue is. It also allows you to click a link on the message to take you to the line of code in the script window to the left. This feature has really helped me out a lot over the past few months.
Profile Your Code to Find Inefficiencies
Finally, Another tab on the main toolbar is Profile. This is very useful to track down bad code.
To profile code press the Start Profiling button. Then run your script, interacting with is as necessary. Once you are done, press the same button to stop profiling.
Now you can see how many times a function is called and how long it executes. You can now track down inefficiencies in your script and make it better.
So the next time you are debugging an AJAX application targeting IE, do not fire up FireFox to debug it, just use the browser you are targeting. If you were at MIX this year I hope you attended the mini session on the IE 9 developer tools. The toolset only gets richer. It even bakes in a mini version of Fiddler. Speaking of Fiddler stay tuned for my next post 