Debugging the Client Side
Disclaimer: Check the date! This post was written way back in . If there are technical things in here, they're more than likely outdated, or there may be better ways to do them by now. You've been warned.
By my definition of Web 2.0, one of the key requirements for any application is cross-browser compatibility. As a company, my employer defines this as IE 6+, Firefox 2+, and Safari 3 beta; all tested on Windows. It’s not ideal, but it covers a huge chunk of the market. This stack is pretty easy to test, but occasionally one of the browsers will throw a curve-ball and that’s where a typical the members of my team, or J2EE developers in general, get lost.
When somebody comes across some weird client-side error and they come looking for my help, I start with three questions:
- Does it validate? (Is it a strict doctype?)
- Is it in quirks mode?
- Did you separate content from presentation from behavior?
I think one and two are pretty obvious, if you’re not following the standards the browser can (and will) do what it wants with your page. Follow the rules and your playing field becomes a lot more level. Number three is a design choice that I prefer for keeping things clean; if your layers are separated, you know what behavior is coming from where. What does this mean? It means style is always stored in an external StyleSheet, JavaScript is always stored in an external JS file, and your HTML markup has no inline event handlers, script blocks, or style attributes. Not only does this make things easier to find and debug it also encourages progressive enhancement and accessible design.
Now that you’ve made sure those three cases are taken care of, do you still have the problem? I’d say 50% of the time the problem is solved, for the rest, here’s what I do. (First things first, make sure your toolbox is in order.)
For debugging CSS, use
Firebug’s Inspect tool to make sure the correct
CSS rules are applying
to your element, this will show you which rules are applying and more importantly, which one
is winning in the case of a conflict. If the problem is not showing up in
Firefox, I’m guessing it also works in Safari,
so it has be an IE issue. Check your floats, check your
widths, and make sure you’re not relying on anything IE doesn’t support, like
min-height or max-height. If you’re still not sure what’s going on, checkout the Microsoft Developer Toolbar.
To get it, go to Microsoft.com and search for “Developer Toolbar,” I’d post a link, but every time I try
bookmarking the page it moves, so it’s probably just easier to search for it. The Developer Toolbar works
similarly to Firebug, but is definitely lacking. If your problem
is in Safari, get a copy of the Webkit Nightly and enable the
Web Inspector. It’s definitely
better than the IE Developer Toolbar, but still not Firebug.
In a pinch, try out the WestCiv
XRAY and
MRI bookmarklets which are easy
enough to install and uninstall on a workstation that is not your own.
If you’re debugging JavaScript, the Firebug console is definitely the way to go for tracing, and you can even make it work on other browsers with their handy JavaScript-based utility. For IE specific errors you can try your luck with the Microsoft Script Debugger (again, search for it), but I find it to be a little bloated. At the time of this writing Webkit offers its own debugger in the form of Drosera, but it’s Mac-only, so unless you’ve got one you’re out of luck there. Finally, you can try out Aptana Studio which offers JavaScript debugging in Firefox (also in IE if you’re willing to pay for it), but I haven’t had a chance to really give it a test drive and at initial glance it seems a little clunky when working with J2EE.
There’s a ton of tools out there for debugging client-side problems, and with a little practice you’ll be debugging like a pro in no time at all. But please, remember one thing, the best offense is a good defense, separate your layers, avoid CSS hacks, and do things the right way the first time.