Freigeben über

Using the F12 Developer Tools to Debug JavaScript Errors

  • Artikel

This content refers to an older version of F12 developer tools. Please visit our latest F12 tools documentation.

F12 tools enables web developers to quickly debug JavaScript code without leaving the browser. Built into every installation of Windows Internet Explorer 9, F12 tools provides debugging tools such as breakpoints, watch and local variable viewing, and a console for messages and immediate code execution.

  • 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

This topic discusses how to use the F12 tools to debug your JavaScript code. The purpose is not to be a comprehensive debugging tutorial, but to highlight the tools that can help get you started working with your own code. From Internet Explorer 9, press F12 to open the tools, and click the Script tab to get started.

In the Script tab, you see the source pane on the left, where you can view your JavaScript code, set breakpoints, and step through the execution path of your functions. In the right pane, you can switch between the console, watch variables, local variables, watch stack, and breakpoint tabs.

Starting and Stopping the Debugger

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.

Using the Console to Find Syntax and Other Code Errors

In most coding projects, errors usually consist of syntax, logical, or data input errors. The console view shows JavaScript errors and exceptions, as well as Document Object Model (DOM) exceptions. From inside your code, you can use the console object to send status and program error messages to the console, rather than user "alert()" calls, or screen real estate. For example, you can add a line such as

window.console.log("The file opened successfully");

to your JavaScript code to get the status in a script without breaking the execution. For more information about using the console, see Using the F12 Tools Console to View Errors and Status.

Make Ugly Scripts Pretty

F12 tools can debug JavaScript on a line or statement level, whether or not the code is displayed that way. Scripts that are condensed so that they appear as a big block of code can still be stepped through. However, it is hard to follow the logic sometimes when the code is in a single block.

To format, or "pretty print" a script, click the Configuration button , and then click Format JavaScript. The following screen shots show before and after formatting a block of JavaScript code.

Breaking Code Execution

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.

Managing Multiple Breakpoints by using the Breakpoints Tab

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.

 

Conditional Breakpoints

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.

In the condition dialog box, add a valid JavaScript statement. When you run the code, it will stop running at that breakpoint if the statement is true. For example, in the following image, the code stops running when the oAudio.paused property is false.

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.

Stepping Through your Code

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.

Watching Variables with the Watch and Locals Tabs

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.

<!DOCTYPE html>
<html>
<head>
    <title>JavaScript debugging example</title>
    
    <script type="text/javascript">

        //create a global variable for our <div>
        var display;

        function init() {
            //initialize only after the HTML has been loaded
            display = document.getElementById("results");
        }


        function firstParam() {
            //set breakpoint here 
            var a = 5;
            secondParam(a);
        }


        function secondParam(a) {
            var b = 10;
            thirdParam(a, b);
        }

        function thirdParam(a, b) {
            var c = 15;
            var d = a + b + c;

            //display to console if F12 tools is open
            if (window.console && window.console.log) {
                window.console.log(a + " + " + b + " + " + c + " = " + d);
            } else {
                display.innerText = a + " + " + b + " + " + c + " = " + d;
            }
        }
    </script>
</head>
<body onload="init();">
        <p><button onclick="firstParam();">Run</button></p>
        <div id="results"></div>
</body>
</html>

  1. In Internet Explorer 9, load the example.

  2. Press F12 to open the F12 tools, and click the Script tab

  3. In the left pane, scroll to the first function, right-click the line that says "var a = 5;", and click Insert breakpoint.

    
function firstParam() {
    //set breakpoint here 
    var a = 5;
    secondParam(a);
}

  4. Click Start debugging, and then on the webpage in the browser, click the Run button.

  5. In F12 tools, click the Watch tab on the right side, and add the variables "a, b, c, and d.".

  6. 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.

Looking at the Call Stack

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.

Debugging Multiple Scripts

Larger webpages typically include several JavaScript files. F12 tools lets you operate across multiple script files as you debug your code. To view a different file, click the down arrow next to the Start debugging button to show a list of scripts that are associated with the webpage. When you use F12 tools to step through code, F12 tools will follow the execution path through multiple files. You can add variables to watch from any script file, and the call stack view shows the execution path across functions contained in different script files.

Changing the Document Mode Setting

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.

Internet Explorer 9 F12 tools cannot fix your code for you, but it can make finding JavaScript errors a little easier.

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