Were possible I cite sources, however I apologize to anyone that I've missed.
If you'd like to try these tips out as you read, jsFiddle can handle gists:
Firebug Command Line API (Firebug, Chrome, ~IE, ~Firefox)
This API may have started in Firebug but is fully supported in many other browsers. Use it to quickly query the DOM, inspect objects, and retrieve references to elements selected in the inspector.
JSFiddle (all browsers)
TIP: If you're going to share the fiddle with others and plan on updating it, remember to set your latest version as the base!
TIP: You can create a fiddle from a gist. See http://doc.jsfiddle.net/use/gist_read.html
http://jsfiddle.net/ http://jsfiddle.net/gh/gist/jquery/1.7/1629116/ http://jsfiddle.net/MarkBennett/YpQKS/
console.dir() (Firebug, Chrome, IE, Firefox)
console.log() is great for recording strings, but sometimes you want to see a proper representation of a JS object. Use console.dir() to see an ineractive representation of a JS object.
This can also be useful for working with jQuery objects which are sometimes hard to distinguish from Array objects using console.log().
console.dirxml() (Firebug, Chrome)
Web developers think in markup, so sometimes you want to see DOM objects in an xml format. dirxml() is there for you.
Selecting elements with $0, $1, $2, ... (Chrome, Firefox)
monitorEvents() (Chrome, Firebug)
Logs to the console events which are triggered on an object. For example, monitorEvents(window, "key") logs key events.
debugger keyword (Firebug, Chrome)
Setting breakpoints in your browser is great, but sometimes you need to conditional trigger debugging. Using the debugger keyword you can invoke your browser script debugging from your source. Just don't forget to remove these calls before you hit production!
Remote Debugging with JSConsole (all browsers)
Track client-side errors with Analytics (All)
This tip comes from Aicke Schulz, who suggested using GA's _trackEvent() call to capture errors from window.onerror in your Analytics stats.
To quote Aicke,
I'm using _trackEvent() from Google Analytics to capture errors from window.onerror. So I can see errors which appear at the user, in every environment. This shouldn't happen that much, but sometimes it does. Good to see if you mistakenly forgot to remove a debug output or forgot to check if an object exists. And you get all the browser informations by ga itself and the ability to filter the errors is quite useful.
Tip 1: Limit the reporting to your own scripts, by checking the domain of the script/file where the error occured in
Tip 2: Check if message and file are not undefined and row > 0 (some browser report bugs in line 0, but there can't be an error)
Tip 3: Do not report errors from browser you do not support (e.g.: < IE7 or < FF3.6)
Tip 4: set opt_noninteraction = true, otherwise every error will influence your bounce rate
To track the event I use:
_gaq.push(['_trackEvent', 'Script Error', message, file + ": Line " + row, undefined, undefined, true]);
I've set this up on http://yegrb.com if you want an example.
XHR Logging (Chrome)
Turn it on by right-clicking in the console.
XHR breakpoints (Chrome)
Debugging communications with the server can be slow and painstaking, especially if you don't have access to your server logs. By setting an XHR breakpoint you can inspect the request send from your browser directly to ensure it's being formatted properly. This is also a good tool for tracking down errand XHR requests in your application. It can be restricted by URL if you don't want to see all requests.
DOM breakpoints (Chrome)
Pause on exceptions (Chrome)
Investigating exceptions in your code can be tricky. Chrome lets you set JS breakpoints on handled and unhandled exceptions.
Are you debugging minified code in production? This can't restore your original variable names, but it will add spacing and breakpoints to make the source more readable while you debug.
Webkit Remote Debugging (Chrome, Playbook, more soon?)
A remote debugging protocol is now supported in WebKit and is slowly being added to WebKit based products. This allows you to connect Developer Tools to instances of WebKit running on another device on your network. Both iOS and Android are expected to support this in future releases but have made no specific announcements.
about:debug (Android 2.3+)
Enter about:debug in the url then check your settings. Try outputting to the console.
How to contribute
- Fork the gist on GitHub
- Edit it online in http://c9.io/markbennett/1629116
I would especially like to thank:
- Paul Irish for his great YouTube videos
- http://www.youtube.com/watch?v=nOEw9iiopwI (Google Chrome Developer Tools: 12 Tricks to Develop Quicker)
- Aicke Schulz for the Google Analytics tip
- The Chrome team
- Mozilla and the Firebug team
- Microsoft and the Internet Explorer team (I've almost forgiven you for that whole IE6 thing.)