Here is a great presentation on the Chrome developer tools by Paul Irish and Pavel Feldman. PDF notes available from Google. A delightful Chrome Developer tools cheatsheet is also available in PDF and PNG formats from Paul’s colleague Boris Smus.

General info

  • Chrome developer tools are roughly equivalent to Firebug in Firefox (but with some newly added cool features).
  • Dev tools are actually made out of CSS / Javascript / etc themselves!

Styling control and CSS manipulation

  • Chrome keeps track of in-browser changes to the stylesheet (even has version control).
  • In the developer version of the browser you can easily save your new stylesheet by right clicking on the stylesheet in ‘resources’ in Chrome and selecting ‘Save as’
  • You have full control of formatting in the style editor now too – works closer to a full editor in the browser.

Network interaction

  • In Chrome, you can get raw request/response/cookies information sent for each request in a page
  • You can also see an individual item’s timing information (dns lookup / wait / transfer / etc)
  • You see a consolidated timeline
  • All of this information comes from the Chrome network stack

Console API

  • There is more than just console.log (and you can pass lots of parameters to console.log, too)
  • dir(node) gives you the DOM properties of the passed node
  • inspect(node) jumps to the element pane, with the passed element selected
  • $0 (in the console) refers to whatever element is currently selected in the ’element’ pane - this is useful to execute script against the selected element
  • The copy(text) method can copy text to the clipboard for you. You can actually copy($0.innerHTML) to copy the selected element’s body text to the clipboard.

Script debugging

  • You can use the debugger with breakpoints (just like you might use Visual Studio or Firebug)
  • You can also reveal an element in the ’elements’ pane, right click on the element in the pane and select ‘break on subtree modifications’. (Holy crap this is useful for debugging things you’re unfamiliar with!) Be sure to use the call stack information in the developer tools with this one. The first item you’re likely to see when using jQuery is some jQuery innards – but go further up the call stack and you’re likely to see what code is causing that bit of HTML to get modified. Also: check the user friendly message in the scripts panel that indicates why execution was paused – it’ll tell you exactly what element was modified.
  • You can also break on various DOM events (see the ‘Event Listener Breakpoints’ panel in ‘scripts’). Useful for debugging timers & keyboard event bugs – when you only know the type of event that might be triggering something.
  • You can also explore page script innards using the ’timeline’ pane - you can click on items in the left side of the timeline page and go to the line of code that triggered that part of the timeline in the scripts page.
  • Just like the style changes, you can make script changes directly in the scripts panel almost like a nice script IDE.
  • You can get nicely formatted code by pressing a tiny button in the bottom of the scripts panel (developer build only). You can still use breakpoints after the code is reformatted.