Home » JavaScript » Javascript debugging tips using the Chrome Dev Tools, deb.js and more

About Aleksey Novik

Aleksey Novik
Software developer, Likes to learn new technologies, hang out on stackoverflow and blog on tips and tricks on Java/Javascript polyglot enterprise development.

Javascript debugging tips using the Chrome Dev Tools, deb.js and more

In this blog post we will go over some useful tips and tricks for debugging client-side Javascript using the Chrome Dev Tools. We will focus on situations where we actually don’t know where to put the breakpoint in the first place.

Let’s go over the following topics:

  • Find out what code is changing a section of the page
  • Find out who is doing a certain ajax request
  • conditional breakpoints
  • event breakpoints
  • programmatic breakpoints
  • Frequently used Debug snippets
  • Add a breakpoint before a given function
  • Search an object for matching properties
  • Break when an object property is accessed
  • Find out who is calling a function using deb.js

The Chrome Dev Tools debugger

Let’s start by opening the Chrome Dev Tools and setting up a breakpoint. Use the shortcut Ctrl+Shift+I or Cmd+Option+I, then choose the sources tab. Choose a source and set up a breakpoint by clicking on the line number:

breakpoint

The problem is, in many situations we don’t know where to put a breakpoint in the first place. This can happen for example while debugging a program that we didn’t wrote ourselves.

Let’s start by seeing how the Chrome Dev Tools can help in several of these situations.

What code is changing this section of the page?

One common scenario happens when a section of the page is being modified, but its not entirely clear by which part of the code. By pointing and right-clicking the HTML element on the page, it’s possible to setup a breakpoint that will be triggered when that part of the page is modified:

break-on-modifications

There are three ways to detect modifications on a section of a page:

  • subtree modifications: the breakpoint is triggered if the element or any of it’s sub-elements is modified. This is the most frequently option used.
  • Attribute modifications: the breakpoint is triggered when an attribute of the element is changed
  • Node removal: triggered when the element is removed from the document

Who is doing this Ajax request?

Another situation that can happen is when a certain ajax request is being made, but we are not sure what part of the code is doing it.

To answer that question, on the sources tab there is a XHR breakpoint section, where it’s possible to add Ajax breakpoints by clicking Any XHR:

ajax-breakpoint

Alternativelly by clicking the plus sign on the section header, it’s possible to add an ajax breakpoint that breaks only if the url of the request contains a matching string.

Conditional breakpoints

Sometimes we don’t want a breakpoint to be triggered every time that the code goes through a given code line. For example, we might want to trigger the breakpoint only if a certain argument of a function (such as an id) has a certain value.

A condition can be added to the breakpoint by right-clicking on the line number and choosing Edit breakpoint:

conditional-breakpoint

Any condition can be added that uses any of the locally accessible variables.

Event breakpoints

Besides Ajax requests, all sort of events might be made to trigger a breakpoint: mouse clicks, double clicks, blur/focus events, setTimeout, etc. These breakpoints can be set in the sources tab, in the Event Listener Breakpoints section:

all-breapoints

Programmatic breakpoints

It’s possible to trigger a breakpoint simply by adding the following code line to a Javascript program:

debugger;

When the code reaches this line, the debugger will be triggered just like if a breakpoint was set on that same line.

This functionality is useful for creating debug tools, or as an alternative to manually setting breakpoints.

Frequently used debug snippets

The Chrome Dev Tools give the developer the possibility to save a small script for future use. This functionality is available in the sources tab, on the sub-tab Snippets:

snippets

This functionality can be used for storing frequently used debugging snippets, made by you or other developers. Some of the most useful snippets I came across are from Paul Irish (Google Dev Tools evangelist).

By copying those snippets into your Dev Tools, you can have them always accessible from the console and ready to use. Let’s go through some of them in the following sections, and then finish off with deb.js.

Add a breakpoint before a given function

The stopBefore.js allows to setup a breakpoint that is triggered just before a certain function is called. For example, this will trigger a breakpoint just before the document.getElementById function is called:

stopBefore(document, 'getElementById')

Search an object for matching properties

The grep.js snippet allows to search an object and its prototypical chain for properties that match a given search criteria.

For example this instruction will search for all properties matching get in the document object:

grep(document, 'get');

Break when an object property is accessed

The debugAccess.js allows to trigger a breakpoint when a given property is accessed. For example this will trigger a breakpoint each time document.cookie is called:

debugAccess(document, 'cookie');

Find out who is calling a function using deb.js

To finish our tour of Javascript debugging tools and techniques, let’s have a look at deb.js, a minimalistic JavaScript debugging library.

Start by adding the following script to the top of your page, before any other script is loaded:

<script src='deb.min.js'></script>

Then mark a function for being traced by calling .deb()on it:

var calculateSomething = function(cb) {
    // ...
}.deb();

The next time the function is called, the following output is generated to the console:

687474703a2f2f776f726b2e6b726173696d697274736f6e65762e636f6d2f6769742f6465626a732f6465626a732e6a7067

As we can see, deb.js has printed the arguments, the stacktrace of who is calling the function together with the line number of each function call, the return value (if any) and the execution time.

Final Thoughts

These debugging techniques should cover the most frequent troubleshooting scenarios. Depending on the problem, many times it’s better to use console.log instead of using a debugger, especially if the different logging levels are used.

The logging statements can be turned off in production mode, and turned back on to help troubleshoot a given problem.

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Web Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. Building web apps with Node.js
2. HTML5 Programming Cookbook
3. CSS Programming Cookbook
4. AngularJS Programming Cookbook
5. jQuery Programming Cookbook
6. Bootstrap Programming Cookbook
and many more ....
I agree to the Terms and Privacy Policy

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of