Anyone who has written JavaScript for the web browser knows the frustrations you can experience while debugging it. This gist is collection of JavaScript debugging tips I've used and collected. Please fork, contribute and share.
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:
http://jsfiddle.net/gh/gist/jquery/1.7/1629116/
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.
http://getfirebug.com/wiki/index.php/Command_Line_AP
Being able to debug JavaScript often means reducing an error to it's most basic components. JSFiddle is a great way to do so, and then communicate this to other collaborators. You can signup to link fiddles your profile.
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.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().
Web developers think in markup, so sometimes you want to see DOM objects in an xml format. dirxml() is there for you.
Sometimes you haven't worked out the right query to select and element yet. In that case, try inspecting it in the Developer Tools. Select the element you're interested in from the Elements tab, then reference it in your JavaScript using $0. Previous selections map to $1, $2, etc.
Logs to the console events which are triggered on an object. For example, monitorEvents(window, "key") logs key events.
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!
When remote debugging isn't available the next best option is JSConsole.com. You can launch it on your desktop, then insert a script tag into the page you would like to debug. You can then run JavaScript commands in the browser on your desktop and see the results of running the JavaScript in the page you're debugging.
http://jsconsole.com/remote-debugging.html
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.
https://plus.google.com/104431949275766772757/posts/N1qwzwuAZd1 https://plus.google.com/110776836375046575411/posts
Turn it on by right-clicking in the console.
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.
Curious which JavaScript code is modifying your DOM elements? You can right-click an element the inspector and then break when it's attributes or sub-tree are modified, or when it's removed.
Investigating exceptions in your code can be tricky. Chrome lets you set JS breakpoints on handled and unhandled exceptions.
TODO
When your browser doesn't pretty print JavaScript, there's a website that will!
Think you know what's causing an exception, with Chrome you can edit your JavaScript without reloading the page to test your changes.
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.
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.
http://www.webkit.org/blog/1620/webkit-remote-debugging/
Enter about:debug in the url then check your settings. Try outputting to the console.
- 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)
- http://www.youtube.com/watch?v=4mf_yNLlgic (Become a Javascript Console Power-User)
- 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.)