Firefox extension debugging

One hugely important thing in coding is debugging. Unfortunately, a lot of Javascript debugging gets done via alert() calls. This gets awkward quickly, with the alerts affecting timing, and just being annoying if you have to dump large amounts of data out.

Firebug is a great development tool, and has a really handy logging interface that you can dump debugging info to. Just calling console.log(whatever) will dump it to the main Firebug interface as text that you can copy/paste, scroll through, etc.

If you’re developing a Firefox extension, this debugging capability is really useful. Except, calling console.log() doesn’t work, console isn’t defined for the browser, only for each window.

The trick? Call it directly from the Firebug extension object.

Firebug.Console.log()

Be sure to capitalize both Firebug and Console, and you’ll be good to go. In addition to having great capabilities for logging, the console will prevent your debugging messages from popping up to your users, in case you leave some code where it shouldn’t be.

By the way — if you found this helpful, check back here in a few days. I’ve submitted a presentation proposal to SXSW for Firefox extension development, where I’ve got tons of info for creating extensions for web applications. They collect votes from the community, and I’d like your support. Plus, if the presentation goes through, I’ll be collecting lots of my best tips and putting them online as a resource for the attendees. That means you’ll get all of them too, and you don’t have to go anywhere! 😀

Edit (2008-08-21: Added link for SXSW voting panel)

Javascripting

I’ve been writing a lot of JS lately, and I wanted to take this opportunity to drop some knowledge right here.

Lots of languages have support for some type of for-each-looping. This is great for looping over associative arrays, and even regular arrays, since it’s a bit cleaner than the standard for-loop. Sadly, Javascript doesn’t totally support this. There is a for-each equivalent in JS, but it’s a bad choice to use, since in JS, everything is an object, and objects can be accessed with different notations — you can either do thing.property or thing[“property”]. This notation should throw a hint as to why looping for-each isn’t the same as other language — if you try and loop over everything in an Array, you’ll also get methods that have been assigned to the Array object. Fortunately, Javascript isn’t totally foolish, you won’t get every single method, but you can definitely get some noise. Here’s Mozilla’s explanation of Javascript for-each:

Although it may be tempting to use this as a way to iterate over an Array, this is a bad idea. The for...in statement iterates over user-defined properties in addition to the array elements, so if you modify the array’s non-integer or non-positive properties (e.g. by adding a "foo" property to it or even by adding a method or property to Array.prototype), the for...in statement will return the name of your user-defined properties in addition to the numeric indexes. Also, because order of iteration is arbitrary, iterating over an array may not visit elements in numeric order. Thus it is better to use a traditional for loop with a numeric index when iterating over arrays.

It’s a shame, because a nice for-each is some of my favorite sugar in a programming language. But, I like Javascript enough that I will forgive it for this. I have a suspicion that with some type checking, a more traditional for-each might be possible, but that’s for another time.

I also found the site of a very cool dude, Kent Brewster. Just one example of his awesomeness is found in his article on hardened Javascript. I also really like that he makes notes and lists and saves information; it’s probably one key to his success.