Debugging JavaScript with Firefox

Firefox_Debugging_Plugins.jpgHere 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.
  • Install the JavaScript Debugger (aka. Venkman, http://www.mozilla.org/projects/venkman/).

Optional Firefox Extensions:

  • Install View Source Chart (http://jennifermadden.com/scripts/ViewRenderedSource.html)
  • Install the Load Time Analyzer (by Google).
  • If you are running on Windows, you might want to install IE Tab (http://ietab.mozdev.org/).
  • 200+ other developer extensions are listed at https://addons.mozilla.org/search.php?cat=4.

Firefox Configuration:

  • Make sure the page cache is disabled (Tools | Web Developer | Disable | Disable Cache)
  • Numerous settings are available under Tools | Web Developer | Options | Options (not to be confused with Tools | Options).
    • Miscellaneous | Open the JavaScript console when the current page generates a warning/an error — Actually, you probably won’t want to do these, or you’ll be inundated.
    • Sidebar | Open the DOM Inspector in the sidebar — If you do not have dual monitors, then you might prefer this.
    • Sidebar | Open the JavaScript console in the sidebar — If you do not have dual monitors, then you might prefer this.
    • Note: View Source | “View Source in a tab instead of a window” does not seem to work.
  • Be sure to close and reopen Firefox immediately after changing any options to make sure they stick.

Debugging HTML, CSS:

  • Use Display Element Information to inspect the properties of the page (Tools | Web Developer | Use Information | Display Element Information, or Ctrl+Shift+F)
  • To use the View Source Chart extension, right click on a web page and select “View Source Chart” from the context menu. (To view a frameset document, select “View Source Chart” from the View menu.)

Firefox Console

Debugging Javascript (using Venkman, the JavaScript Console, and the DOM Inspector):

  • 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 view errors via Venkman (as opposed to using the Console), set Debug | Error Trigger | Trace Errors on and set Debug | Throw Trigger | Trace Exceptions on.
  • 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.

Trackbacks & Pings

Comments

  1. Firebug > All

    You can replace the DOM Inspector, Javascript Debugger and View Source Chart extension with Firebug, and as a bonus, it’s a lot easier to use.

    http://getfirebug.com

  2. Here’s another vote for Firebug, one of the best tools for debugging all things javascript(including ajax), and there is a javascript version that’s not too bad if you’re using a non-firefox browser.

  3. I can’t believe Firebug wasn’t mentioned! It is by far the most advanced plugin for Firefox. I’ve seen Joe Hewitt demonstrate it and it was phenominal.

  4. 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.

  5. 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.)

  6. Yeah, I’ll quadruple the “what about Firebug?!” :)

    I’ve done that too before, where I write a blog post and by the time I publish it some of the information is no longer valid.

    I find that Firebug and a good editor with Javascript syntax highlighting is all I need now.

Post a Comment


Your email is never published nor shared. Required fields are marked *



© 2006-2007 Maxim Software Corp.  All rights reserved.