Productivity and technology tips to get you jacked!

Debugging JavaScript with Firefox

April 17th, 2007 — Craig

Here are some miscellaneous tips for debugging HTML, CSS, and JavaScript in Mozilla Firefox.

They include references to Firefox extensions (plug-ins) that you will need or want, as well as tips for configuring Firefox, how to actually invoke the debugging procedures, and a few shortcuts to keep in mind. A number of landmines are also pointed out along the way. (Please avoid stepping on those, because it gets messy.)

Minimally Required Firefox Extensions:

Does your installation of Firefox have a DOM Inspector option on the Tools menu? If not, reinstall Firefox with the Developer Tools option turned on (Custom | Developer Tools).

Install the Web Developer Extension (http://chrispederick.com/work/webdeveloper/), if you have not already done so.

View the page source (right-click | This Frame | View Frame Source) and verify that the JS is actually in the page.

Use the Javascript console (Tools menu) to view error and log messages. It can also evaluate JavaScript code on the fly.

The JavaScript Console (where errors are reported) and Venkman are not associated. If you click on the link for where the Console says an error occurred, you’ll see the source code in Firefox’s View Source window, not in Venkman. You cannot even cut and paste the script name very easily. (First, right click on the error and use Copy to grab the whole error message and info. Paste it all into Notepad. Now, copy just the URL and paste that into the File | Open dialog of Venkman. You’ll then have to manually scroll down to find the line number in question.)

To set a breakpoint on JavaScript code that is in a dynamic web application, you have to know the correct URL (which can be tricky to determine). File | Open (Ctrl-O) and paste in the URL (including the “http://”). Tip: If the page generates an error, you will see this URL in the Console. (If error tracing is on in Venkman, you’ll also see the error logged in the Interactive Session pane of the debugger, however it will only show you the URL for the outer frame page).

The Firefox DOM inspector (Ctrl+Shift+I) is difficult to navigate, especially with frames. The search function expects you to know the exact name of the attribute. (You cannot search for any element with any attribute that has a value of, say, “picklist”. You have to know that you are looking for an attribute called “name” as in ).

Do not close Venkman, just minimize it. There’s a Firefox bug that prevents you from re-opening Venkman once it’s closed. If you close it accidentally, you’ll have to close all of the other Firefox windows (console, browser, script views) and then manually kill the firefox.exe daemon (via the task manager).

The Local Variables inspector in Venkman is hard to navigate with so much of the internals showing. (The signal-to-noise ratio is upwards of 10:1.) So, in Venkman, it’s often easier to proactively set a watch (/watch-expr someExpression).

Watch expressions are only (re)evaluated when execution stops, when the /eval command is used, and when the /watch-expr command is used.

ESC = gives focus to the input box located below the Interactive Session.

F12 = Step over

F11 = Step into

Sometimes, the page names in a dynamic web application are all HTTP parameters. In that case, every source code tab in Venkman will be labeled as just “App.” This means, you’ll have to read the code to figure out which page you are actually on (e.g. the outer frame vs. the actual page code of interest). Also, if you sit for a while and then refresh the source code, it might change to the code for the login page (because the session timed out), yet the old page will still be displayed in the browser. This can be very confusing.

Oops. Color me chagrinned. How could I forget about FireBug? Here’s what happened: I wrote the tips above several months ago, originally on behalf of a client. (Over formalities of copyright, I only just obtained permission to reprint them here.) As I recall now, we attempted to use FireBug at the time, but it didn’t work for our particular situation. (Of course, I can’t for the life of me remember why, other than to say that the project was quite complex.) Anyway, the bottom line is, yes, FireBug is highly recommended. I wish I could have used it on that project.

FireBug is nice, but it’s got showstopper problems on sites with lots of content in dynamically-loaded iframes. The HTML “rebuilder” does not properly respond to updates to iframes, making it essentially useless for such sites. (Before the 1.0 release, it worked, sort-of, but the 1.0 release broke it and I haven’t been successful in getting the attention of the developer.)