How the new Breakpoints sidebar helps you debug faster
Published on
Googler working on Chrome DevTools.
UX Designer at Google
Interested in helping improve DevTools? Sign up to participate in Google User Research here.
If you’re on Chrome 111 or later, you might have already noticed that we’ve changed the design of our breakpoint sidebar. With Chrome 113, the new sidebar entirely replaces the old design. Our goal with the redesign was to improve the breakpoint workflow by:
Providing a better overview on all breakpoints that are set. Making common user workflows with breakpoints easier to access and more intuitive. Making cool existing breakpoint features visible.
This post assumes that you are already familiar with debugging using breakpoints. If you haven’t used breakpoints before, head over to this overview on breakpoints and learn more about how you can use breakpoints to debug your code.
Now, let’s have a look at what the redesign offers, and how you can make use of the new sidebar! Note that the redesign concentrates on making existing features more intuitive to use and easier to access, instead of adding new features.
Pause on exceptions to investigate why your code is throwing an error
Does your code throw an exception? Fret not! Chrome DevTools allows you to pause on exceptions to stop execution at the point where your exception is thrown. This can help you to investigate and better understand the circumstances under which your code throws an error. You can choose whether you want to pause on caught exceptions, uncaught exceptions, or both, by checking the corresponding checkboxes in the sidebar.
For Node debugging, pausing on caught exceptions with Chrome 113 is only possible if also pausing on uncaught exceptions. This is a dependency that previously existed and needs to be kept for Node LTS compatibility reasons. As soon as Node LTS release 18 is no longer supported, we will also allow independent pausing for Node. Follow crbug/1382762 for updates.
Manage your breakpoints: expand relevant breakpoint groups, and collapse others to focus on what’s relevant
Breakpoints may be spread across several files. The breakpoint sidebar groups breakpoints according to the file they belong to. Focus on only those that matter for your current debugging session by expanding the relevant breakpoint groups, and collapsing the remaining ones.
If several files happen to have the same file name, Chrome DevTools will also try to show you a part of the file path next to the file name that can help you to differentiate between files.
Manage your breakpoints: one click to jump to code, remove, or enable/disable breakpoints
The breakpoint sidebar allows you to accomplish common tasks with one click. Here’s an overview of how you can ...
Navigate to the breakpoint location in the Code Editor. Remove one breakpoint or all breakpoints within a file. Enable or disable one breakpoint or all breakpoints within a file.
And all this with one click! Of course, these options are also available in the context menu:
Jump to the breakpoint location by clicking on the breakpoint code snippet
Do you want to check where in the code you have set your breakpoint, and analyze the surrounding code? Just click on the code snippet of a breakpoint within the sidebar, and it will open the code location in the code editor.
Remove a single breakpoint or all breakpoints within a file by clicking on the remove button
Hover over a breakpoint or a breakpoint group to reveal a remove button that removes a single or all breakpoints in a file on click.
Disable a single or all breakpoints within a file
Check or uncheck the checkbox next to a breakpoint to enable or disable it.
To enable or disable all breakpoints in a file, hover over the breakpoint group and check or uncheck the checkbox that appears next to the file name.
Make use of these lesser known breakpoint features: conditional breakpoints and logpoints
If you want to know more about the differences between regular breakpoints, conditional breakpoints, and logpoints, head over to our documentation on breakpoint types which explains how you can use these different breakpoint types to debug your code.
TLDR: conditional breakpoints stop execution only if a condition that you specify is true. Logpoints, on the other hand, are the counterpart of using console.log, but in Chrome DevTools.
Edit breakpoint conditions or change your logpoint log by editing a breakpoint
Edit a breakpoint condition or log by hovering over a breakpoint and clicking the edit button that appears. This opens a dialog for changing the breakpoint type and the details of your breakpoint.
Alternatively, select the line of the breakpoint in the code editor and type in Control+Alt+b on Linux and Command+Alt+b on Mac to open the breakpoint edit dialog.
You can also quickly double-check your condition or logpoint log by hovering over the breakpoint in the sidebar:
Conclusion
Our goal behind the redesign of the breakpoint sidebar was to make debugging with breakpoints easier. Most importantly, we aimed to make things more structured, and easier to access and understand. We hope these improvements will help you in your next debugging session!
If you have suggestions for further improvements, let us know by filing a bug!
Download the preview channels
Consider using the Chrome Canary, Dev or Beta as your default development browser. These preview channels give you access to the latest DevTools features, test cutting-edge web platform APIs, and find issues on your site before your users do!
Getting in touch with the Chrome DevTools team
Use the following options to discuss the new features and changes in the post, or anything else related to DevTools.
- Submit a suggestion or feedback to us via crbug.com.
- Report a DevTools issue using the More options
> Help > Report a DevTools issues in DevTools. - Tweet at @ChromeDevTools.
- Leave comments on our What's new in DevTools YouTube videos or DevTools Tips YouTube videos.
More from the Chrome DevTools team
Subscribe to Chrome DevTools blog to stay up to date with the DevTools news.
Published on • Improve article