Web Inspector ReferenceEvent Breakpoints

Event Breakpoints can be useful when debugging DOM interactions in JavaScript. Event Breakpoints have two different types: Global Event Breakpoints and Specific Listener Breakpoints.

Global Event Breakpoints

These Event Breakpoints can be added by clicking on the [Create Breakpoint] in the top-right of the Breakpoints section in the navigation sidebar in the Sources Tab.

  • All Animation Frames
    Whenever any requestAnimationFrame callback is invoked, execution will pause JavaScript execution inside the callback, but before any of its code is run.
  • All Timeouts
    Whenever any setTimeout callback is invoked, execution will pause JavaScript execution inside the callback, but before any of its code is run.
  • All Intervals
    Whenever any setInterval callback is invoked, execution will pause JavaScript execution inside the callback, but before any of its code is run.
  • All Events
    Whenever any DOM event is fired, execution will pause JavaScript execution inside the DOM event listener callback, but before any of its code is run. This includes any custom DOM event, such as those fired by dispatchEvent.
  • Event Breakpoint… This will have the same effect as the All Events Event Breakpoint, but it will be limited to a specific DOM event name (including custom DOM event names) instead of for every DOM event.

All Global Event Breakpoints are preserved across Web Inspector sessions.

Specific Listener Breakpoints

Global Event Breakpoints are a great way of seeing whether a DOM event has any listeners or to debugging issues related to DOM event dispatch ordering (e.g. capturing vs. bubbling).

But sometimes, the issue is related to a specific DOM event listener, like a specific callback for a click DOM event on a specific DOM node.

In these cases, setting a Global Event Breakpoint for click wouldn’t be ideal, as there may be other click DOM events that are fired on other nodes or with other callbacks.

Additionally, setting a JavaScript Breakpoint inside the code of the callback (assuming you know where it is) may also not be ideal as the callback might be used for other DOM event callbacks, or even called unrelated to DOM events.

The ideal solution would be to be able to set a breakpoint on the callback such that it only fires when that callback is invoked in response to the specific DOM event being fired on the specific DOM node.

This can be done in Web Inspector from the Event Listeners section in the Node panel in the details sidebar in the Elements Tab.

The Event Listeners section enumerates all of the DOM event listeners for the selected DOM node, and for all of its ancestors, and provides information about each:

  • Target is a representation of the DOM node target.
  • Event is the name of the DOM event.
  • Function shows information about the callback, like function name and/or source code location.
  • Capturing will only be shown if that specific DOM event listener was added with a useCapture option.
  • Bubbling will only be shown if that specific DOM event listener was added without a useCapture option (or if it was set to false).
  • Attribute will only be shown if that specific DOM event listener was added via an HTML attribute.
  • Passive will only be shown if that specific DOM event listener was added with a passive option.
  • Once will only be shown if that specific DOM event listener was added with a once option, which means that the specific DOM event listener will be automatically removed after it’s executed.

In addition to this information, there are also two checkboxes:

  • Enabled, when unchecked, will prevent that specific DOM event listener for that specific DOM event for that specific DOM node from ever being fired, effectively “removing” the DOM event listener entirely.
  • Breakpoint, when checked, will set a Specific Listener Breakpoint as described above.

The Event Listener section will update as DOM event listeners are added and removed, and the Enabled and Breakpoint checked state will be preserved when changing DOM nodes.

Each sub-section also has a [Options] in the top-right when hovered that provides a quick way to enable/disable or set/remove Specific Listener Breakpoints on all event listeners in that sub-section.

The Event Listener section can also be changed to Group By Target instead of the default Group By Event by clicking on the [Grouping Method] in the top-right.

Specific Listener Breakpoints are not preserved across Web Inspector sessions.

State

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

  • the Event Breakpoint was manually disabled . 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 will toggle between enabled and 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 Event Breakpoint.

Icon legend:

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

Written January 14, 2020 by Devin Rousso

Last updated August 10, 2020 by Devin Rousso