This content refers to an older version of F12 developer tools. Please visit our latest F12 tools documentation.
- Starting and Stopping the Debugger
- Using the Console to Find Syntax and Other Code Errors
- Make Ugly Scripts Pretty
- Breaking Code Execution
- Managing Multiple Breakpoints by using the Breakpoints Tab
- Conditional Breakpoints
- Stepping Through your Code
- Watching Variables with the Watch and Locals Tabs
- Looking at the Call Stack
- Debugging Multiple Scripts
- Changing the Document Mode Setting
- Related topics
When you first open the F12 tools and click the Script tab, your code appears on the left and the console on the right. In the console you might see a message: "Refresh the page to see messages that may have occurred before the F12 tools were opened. " When you refresh the webpage, the console shows you any errors or warnings that the browser has raised.
To be able to set breakpoints, view watch and local variables, and see the call stack of a series of functions, click the Start debugging button. By pressing the Start debugging button, you refresh the webpage and restart the code in the debugger.
Setting breakpoints in F12 tools is similar to binary code debuggers like Microsoft Visual Studio. In the left pane, click to the left of the line of code you want to break on. Breakpoints are toggled, so you click to add them, and click again to remove them.
You can add as many breakpoints as you want to your code. You can either right-click a line of code and click Insert breakpoint, or click in the left margin next to the statement you want to break on.
With F12 tools, you can set a breakpoint at the statement level, even if those statements are in a multi-statement block or line. This allows you to break within a condensed section of code. The best way to set a breakpoint under these conditions is to right-click the code, and click Insert breakpoint from the shortcut menu. You can also use the script formatting (pretty print) described previously to format the lines to make it easier to click in the margin.
If you have a large codebase that has many breakpoints or even across multiple files, the Breakpoints tab can help you keep track of them all. In the Script tab, click the Breakpoints tab in the property or right pane. See the following image for an example.
From the Breakpoints tab, you can enable or disable, delete, select, and copy breakpoints without having to go to the exact place you set them. To turn a breakpoint on or off, click the check box next to the setting that you want to change. You can jump immediately to the breakpoint in the code by double-clicking the listing as well. You can select multiple breakpoints by pressing the Control key, and clicking on several breakpoints.
The Breakpoints tab also has a shortcut menu (available when you right-click) that allows you to bulk delete, enable, disable, or copy breakpoints. The options are shown in the following table.
|Menu item||What it does|
|Delete||Removes a breakpoint permanently.|
|Delete all||Removes all breakpoints permanently.|
|Enable all||Sets all check boxes in the list.|
|Disable all||Clears all check boxes in the list.|
|Condition||Lets you set a conditional breakpoint for a single breakpoint. This option is disabled when multiple breakpoints are selected.|
|Copy||Copies the text of selected breakpoint descriptions.|
|Select all||Highlights all breakpoints in the list.|
|Go To source code||Navigates left code pane to show the selected breakpoint. This option is disabled when multiple breakpoints are selected.|
Breaking unconditionally on a line of code is helpful, but breaking when a property or variable reaches a specific value is even more powerful. To break when a specific value is reached or set, set the breakpoint and then open the Breakpoints tab. Right-click the breakpoint you want to use, and click Condition.
You can have a single condition, or by using logical statements, break on a more complex condition. Keep in mind though that the scope for variables and objects will be the same as if you were inspecting them in the watch window at the breakpoint. If you use a condition that is not in scope, the condition will not evaluate as true.
When code execution stops at a breakpoint, you can use the navigation buttons to continue (F5), Break all (Ctrl+Shift+B), or step into (F11), step over (F10), or step out (Shift+F11) of a function. While execution is paused at a breakpoint or being stepped through, the debugging window is essentially modal.
Because of this, you need to stop debugging (Shift+F5) , or continue (F5) before interacting again with the webpage. This is good to keep in mind if your webpage appears to become unresponsive . If you have a number of windows open and the debugger is not on top, it could be waiting for a response on a breakpoint. If this happens, find the debugging window for that webpage and press F5 to continue, or press Shift+F5 to stop debugging, to return control to your webpage.
The Watch tab allows you to set and watch variables in your code. It lists the name, value, and type of variables you specify. You can click the line marked click to add... in the Watch tab and type in a variable name. If you do not want to type the variable name, you can copy and paste it into the watch list.
The watch variable list displays values whether you are debugging code or not. When you have debugging turned on and are tracing through code, or have breakpoints set, the scope of the variable values in the list are where you are in the script. If debugging is turned off, the scope is global, and only global variables will show values.
Unlike the Watch tab, which shows variables whether in or out of scope, the Locals tab views shows only variables in the current scope. You do not need to add variables to watch, as it updates with all the variables available as the scope changes.
To see the difference, open the following example in Internet Explorer 9 and follow the steps.
- In Internet Explorer 9, load the example.
- Press F12 to open the F12 tools, and click the Script tab
- In the left pane, scroll to the first function, right-click the line that says "var a = 5;", and click Insert breakpoint.
- Click Start debugging, and then on the webpage in the browser, click the Run button.
- In F12 tools, click the Watch tab on the right side, and add the variables "a, b, c, and d.".
- Step through your code by pressing F11, or by clicking the Step into button, and watch the variables on the Watch tab.
You should see the watched values change from undefined to a value as you step through each function.
To see the difference with the Locals tab, press F5 to continue out of F12 tools. In the browser, click the Run button on the webpage to rerun the code and return to the F12 tools. In the right pane of the Script tab, click the Locals tab, and press F11 to step through the functions again. In the local variable list, notice that only the variables that have a value are listed. The Locals view also shows the arguments that are passed to a function, their value, and type.
The Call stack tab lets you see the path that is taken as functions are called from your code. This can help uncover an unexpected code path as a result of a bug. From the Call stack tab, you can double-click any of the functions and be taken to that call in the source code.
Try the example mentioned previously and look at the Call stack tab while you trace through the functions.
In the Call stack tab, the current function or location is always on the top (pointed to by the arrow, both in the Call stack tab, and in the code margin). When you double-click any of the functions in the list, the statement that called the function is highlighted.
The Document Mode setting on the right side of the Menu bar is available in any tab of F12 tools, but it can be especially helpful when debugging code in the Scripts tab. Internet Explorer 9 lets you change the document mode to emulate the standards of previous versions of Windows Internet Explorer. In Internet Explorer 9, leaving off a <!doctype> declaration causes the doctype to default to Quirks Mode. When working with a new feature or standard, such as HTML5 audio or canvas, some bugs that might appear to be coding errors could actually be a missing or wrong doctype declaration.
- Getting Started with the F12 Developer Tools
- How to use F12 Developer Tools to Debug your Webpages
- Using the F12 Tools Console to View Errors and Status
Build date: 12/13/2013