Web Inspector ReferenceJavaScript Breakpoints

If you’ve ever used Xcode to debug an application, Web Inspector supports many of the same features, including setting breakpoints.

Left clicking (or right-clicking and selecting Add Breakpoint in the context menu) on any line in the gutter (where the line numbers are) of a JavaScript resource (or any inline <script> s in an HTML resource) will set a JavaScript breakpoint on that line.

What this means is that when JavaScript is about to execute that line, it will instead pause JavaScript execution before it executes the line, allowing you to investigate what’s going on at that point.

State

Breakpoints can either be enabled or disabled . Ideally, your breakpoint will always be enabled , but there are a few reasons why they would be disabled :

  • you’ve manually disabled the breakpoint. Clicking (or right-clicking and selecting Enable Breakpoint or Disable Breakpoint in the context menu) on any breakpoint icon in the navigation sidebar in the Sources Tab or in the gutter of any text editor will toggle between enabled and disabled .
  • the JavaScript breakpoint ‘s location resolves to a line of code that isn’t JavaScript. It’s also possible to set JavaScript breakpoints in HTML files, intended to help debug inline <script> s, but if you put a JavaScript breakpoint on a non- <script> line, it will be permanently disabled .
  • breakpoints have been globally disabled . The global breakpoint control is a button that looks just like a breakpoint located in the top of the navigation sidebar in the Sources Tab.

All enable/disable/delete “toggles” are available in the context menu when right-clicking on any breakpoint. These “toggles” are also present in the context menu when right-clicking on the related resource and will apply to all breakpoints set in that resource.

JavaScript Breakpoints are preserved between Web Inspector sessions, but they are only re-added if a script that matches a JavaScript breakpoint’s url exists in the current page (e.g. JavaScript breakpoints from http://a.com/index.js wouldn’t be shown when inspecting http://b.com/index.js).

Icon legend:

  • enabled (breakpoints globally enabled)
  • disabled (breakpoints globally enabled)
  • enabled (breakpoints globally disabled)
  • disabled (breakpoints globally disabled)

Configuration

JavaScript breakpoints have a few different configuration options, reachable by right-clicking and selecting Edit Breakpoint… in the context menu.

The Condition input allows you to restrict the JavaScript breakpoint to only pause JavaScript execution if the given JavaScript evaluates to a truthy value. This is useful for situations where you only want to pause JavaScript execution once a certain condition is met, such as a variable having a particular value. Keep in mind that the contained JavaScript is evaluated when the JavaScript breakpoint is reached, and may cause additional side effects depending on the code you run as your condition.

Rather than execute arbitrary code, however, you may just want to ignore the first few times the JavaScript breakpoint is reached. If this is the case, setting the Ignore input to any positive integer will prevent the JavaScript breakpoint from pausing execution until it has been reached that many times.

Now you may be wondering what’s an Action. There are four different types:

  • Log Message

    This is basically a “shortcut” for logging values using console.log. The string you provide behaves like a template literal, meaning you can evaluate arbitrary JavaScript so long as it’s inside a ${…}.

  • Evaluate JavaScript

    Arguably the most powerful JavaScript breakpoint Action, it allows you to evaluate any arbitrary JavaScript whenever that JavaScript breakpoint is hit. The given JavaScript is executed as if it were right before the line of code, meaning it will have access to all variables available in that scope before the line in question.

  • Play Sound

    Adding one of these will cause Web Inspector to play a system beep sound whenever the JavaScript breakpoint is hit.

  • Probe Expression

    Probe Expression s can be thought of almost like a mini-Console. Each time the related JavaScript breakpoint is hit, the Probe Expression is evaluated and the result is saved in the Probe panel in the details sidebar in the Sources Tab, allowing you to see how the result of the expression changes during the lifetime of your program. You can use this to observe changes to a specific variable (e.g. this), or to changes in an entire expression (e.g. this.foo === "bar").

If any Action is set, you can also configure the JavaScript breakpoint to Automatically continue after evaluating. This will cause the JavaScript breakpoint to become effectively “invisible”, in that it will never pause execution. JavaScript breakpoints that Automatically continue after evaluating will have a small white triangle (“hollow”) in the icon:

For more information, please read the Breakpoint Options post on the WebKit Blog. Note that it was written in 2015, so some of the design has changed, but much of the functionality is the same.

Special Breakpoints

In addition to line-based JavaScript breakpoints, there are also a few special JavaScript breakpoints that apply globally, regardless of line number.

  • The All Exceptions breakpoint will pause JavaScript execution whenever any exception is thrown if it’s enabled.
  • The Uncaught Exceptions breakpoint is similar to the All Exceptions breakpoint, except that it will only pause if the thrown exception is not caught.
    • This breakpoint is essentially a “subset” of the All Exceptions breakpoint, and is therefore disabled whenever the All Exceptions breakpoint is enabled.
  • Assertion Failures is a useful breakpoint to set when in development, and will pause JavaScript execution whenever console.assert is called.
  • The All Microtasks breakpoint will pause JavaScript execution right before any microtask executes, including functions passed to queueMicrotask or used as part of a Promise chain.

The All Exceptions and Uncaught Exceptions breakpoints are special in the sense that they are non-configurable and cannot be deleted/removed, only disabled.

Both the Assertion Failures and All Microtasks breakpoints, however, can be deleted/removed. If you’ve deleted either of them and want to add them back, doing so is as simple as clicking the in the top-right of the Breakpoints section in the navigation sidebar in the Sources Tab.

Written January 14, 2020 by Devin Rousso, Joseph Pecoraro, and Timothy Hatcher

Last updated January 29, 2020 by Devin Rousso