OdeToCode IC Logo

Debugging JavaScript with Chrome

Thursday, March 15, 2012

The Chrome Developer Tools are a bit quirky, but for script debugging I currently like them the best. Here is a quick brain dump on some areas of interest (these are all in the stable build 17.0.963.79).

Chrome Developer Tools

The Toolbar Under #1

The leftmost button allows you to dock and undock the tools window from the browser window.

The second button opens the Console, which is a helpful JavaScript REPL. You can execute script code in the current debugging context, meaning you can manipulate the DOM, try different CSS selectors with jQuery, or call into libraries loaded on a page to figure out how an API works. Tip: To enter code that spans multiple lines use Shift+Enter to end a line. The console also displays errors, warnings, and log messages, and provides autocompletion (the right arrow key seems to be the safest way to complete, as the ENTER key sometimes doesn't work (I said it was quirky)).

The third button is the "click an element on the page to inspect it" button.

The fourth button toggles the break on exceptions behavior. The debugger can break on all exceptions, break on unhandled exceptions only, or ignore exceptions. Break on unhandled exceptions is a fast way to find broken code.

The fifth button is the pretty print button. If you are trying to step through minified source code to find a bug in a production library, the pretty print feature will at least give you the proper line breaks and white space to read the code. Unfortunately, local variables will still be minified and look like variables from a Fortran program circa 1972 (I,j,k).

The sixth button is the live edit button, where you can click the the source code and change the code on the fly. Like the console window, this is a useful feature to have when you are still trying to figure out how things work. After you change the code the changes are live in the browser and working.

#2 Area: Breakpoints

Like any debugger you can break on specific lines of code. You can also break into code starting an AJAX request (and break only on specific URLs). There are also event listener breakpoints. An event listener breakpoint is useful when you are trying to find who is responding to a click event, for example. Events include timer events, like setTimer, clearTimer, and the timer tick event handler.

The tools also provide  DOM breakpoints, which I use when I'm trying to find who is responsible for changing something in the DOM. With an element selected in the Elements tab, you can right-click and set up a breakpoint if an attribute on the element changes, if someone adds or removes a descendant element, or if someone removes the element from the DOM.

Profiles (#3)

Clicking on the profiles button will bring you to a tab with two primary features – the ability to start CPU profiling, and the ability to take a heap snapshot (once you are on the tab, look for the buttons in the #1 toolbar area).

CPU profiling help you find the functions where a page is spending most of its time.


The heap snapshots are thorough, but it can take some work to go from seeing there is an array holding 10MB of data to figuring out the who, what, where, when, and why.

The Timelines tab also surfaces some interesting visualizations, particularly if you are troubleshooting a slow page load.

Settings (#4)

The gear to the right of the big #4 is where you can change the settings for the tools. There aren't many settings, but you'll find the Disable Cache option useful.

Gravatar James Thursday, March 15, 2012
Well done. What features do you find lacking compared to firebug?
Gravatar Oskar Austegard Thursday, March 15, 2012
Thanks for calling out the Settings - I'd not seen those before, and that's where I finally found the Override User Agent setting - I've been wondering why that is available in Safari and not in Chrome.

I was going to say that my one gripe with the tools was that it's too difficult to watch a variable - that should be available from the context menu - but now I see that too has been added....
Gravatar Ryan Cromwell Thursday, March 15, 2012
Far and away the best setting for those building heavy client/js apps is Settings -> Disable Cache.

Gravatar Paul Thursday, March 15, 2012
>> Well done. What features do you find lacking compared to firebug?

The last time I've debugged with FireBug it crashed too often, so I've tried chrome and stayed with it. My guess would be stability, though the information might not be up to date.
Gravatar scott Thursday, March 15, 2012
@James: Firebug has all the features I need too, but the Chrome tools are easier for me to work with. The commands and buttons just seem to be in the right place. Subjective decision, I know.
Gravatar Ian Patrick Hughes Thursday, March 15, 2012
I tend to think that Chrome's break points and console, might just be easier to work with over FireBug because they are more VisualStudio like in nature. In fact, sometimes I catch myself trying to hit F5 to step through a breakpoint, only to realize that I just initiated a pagfe refresh.

Overall though, these tools make client-side development so much more of a joy.
Gravatar Ron Thursday, March 15, 2012
Nice explanation Scott. I like your site and all of its articles. If i can follow it (not always), everyone can :p
mvark Saturday, March 17, 2012
Interesting info.

My favorite Chrome Dev Tools feature is the listing of unused CSS rules that can be removed. It is provided through the Audits tab along with other performance improvement suggestions -mvark.blogspot.in/...
Gravatar Kelly Martinez Saturday, March 17, 2012
Thanks Scott! Didn't realize there was a disable cache button, will be really helpful for the future.
Gravatar Tarik Guney Sunday, March 18, 2012
What about making an advanced Google Chrome debugging course in Pluralsight maybe?
Gravatar scott Sunday, March 18, 2012
@Tarik - maybe :)
Gravatar Sebastian Sunday, April 1, 2012
Nice article! Twitted

Thank you
Comments are closed.