Every breakpoint you set across all your scripts appears under Breakpoints in the navigation sidebar, as shown in Figure 4-2. Clicking the line jumps the text in the content browser to the line with the breakpoint. The breakpoint icon to the right of the line number allows you to enable and disable the breakpoint without removing it.
You can also set a breakpoint within
<script> tags on HTML resources.
Delete a breakpoint by selecting it in the Breakpoints pane and pressing the Delete key. You can also drag the breakpoint out of the gutter to remove it.
You can set a breakpoint programmatically by calling the
debugger keyword in your scripts. Don’t ship this code to your customers, though, because it will break the execution of your scripts at that point. It is meant for development purposes only.
When a script is paused, you can hover over objects in your script to reveal a token popover containing the object’s methods and properties and their values at the current time, as shown in Figure 4-4.
You can set breakpoints that are only active when a certain condition evaluates to be true. To do so, Right-click the breakpoint in the Debugger details sidebar and select Edit Breakpoint, as shown in Figure 4-5.
A popover appears, prompting you to enter a condition, as shown in Figure 4-6.
The condition is scoped to the current context; any variables within current scope are available to use in this expression. If the condition evaluates to be true, the script pauses at the breakpoint; otherwise, the script continues.
The call stack lists the functions that have been called and have not yet finished returning. The most recently called functions are displayed at the top of the stack, as shown in Figure 4-7. Use this to view the order in which functions are called.
When a script is paused, the call stack shows the chain of functions called to arrive at the paused line. Selecting an item in the stack jumps to where the line is declared in your scripts.
Use the buttons above the call stack to have line-by-line control of where the debugger pauses execution next. The buttons have the following behavior:
Continue—continues execution until the next breakpoint.
Step over—steps to the next line, without descending into any functions called on the current line.
Step into—steps to the next line, descending into any functions called on the current line first. If there are no function calls on the current line, this button behaves like the step over button.
Step out—steps to the preceding frame in the call stack.
The Scope Chain details sidebar displays all the variables set on the page and their values at the moment in time the script is paused. Variables are organized by their scope.
This includes all of the local variables available in the current function’s scope. All variables defined within the current function have their names printed here. Their values appear if they have been set at this point; otherwise, the value is undefined.
There are two variables that appear in the local variables section that you don’t declare explicitly:
arguments variable contains the values of the arguments that were passed into this function, including the implicitly available
this refers to the object this function is a member of (either the object that this method is attached to, or
If you set a breakpoint within a closure, or anonymous function, you see variables appear in the Closure Variables section, as shown in Figure 4-9. Closures have privileged access to the scope of the outer function that calls them.
Variables attached to the global object
window appear under the Global Variables section, as shown in Figure 4-10. This includes global variables you define in your scripts, global variables defined in installed extensions, and methods and properties of