Firebug Console: Best (Cross-Browser) Practices

July 20th, 2009 posted by admin

The Firebug plug-in is an essential and unparalleled tool for (web) UI development.  If you’re not using it, you should be.  But in any case, some of its features can make a lazy (or busy) programmer cause serious problems in other browsers (unless Firebug Lite is installed).

Over the past few years I’ve tried a number of approaches for ensuring that my Firebug console calls don’t cause errors on browsers which either don’t support it or don’t have Firebug installed.  A few approaches I’ve used myself are described here.

1. Checking for existence of the console before each call to it

if (typeof console!="undefined" && console.log){ console.log("blah blah"); }


if (typeof console!="undefined" && console.dir){ console.dir(someObject); }

While this is a safe way to avoid errors when the Firebug console is unavailable its pretty nasty since we don’t want this code repeated all over the place.

2. Creating dummy console methods when they are not available and using console freely

   if (!window.console||!console.firebug){
      var methods = [
         "log", "debug", "info", "warn", "error", "assert",
         "dir", "dirxml", "group", "groupEnd", "time", "timeEnd",
         "count", "trace", "profile", "profileEnd"
      window.console = {};
      for (var i=0; i<methods.length; i++){
         window.console[methods[i]] = function(){};

This method is pretty popular. I saw a few sites which use it, including Twitter.  Sure, it sucks that you have to define the methods of a foreign object in your code (and therefore need to keep that list current), but since you are the one who is using these methods its not a big deal.  If a new method is added to the console and you want to use it, just remember to add it to this list.  In fact, you could take this a step further and check for not just the console, but each of the methods before making a dummy version of it.  (The code currently assumes that all versions of Firebug provide the same methods.)

I sort of like this since it means that you and your colleagues can just use the, now standard, Firebug calls without worrying about potential issues.  And while I don’t advocate using the Firebug console in Production environments, this should protect you from browser errors.  And I wrapped the thing in an anonymous function to create local scope for the methods variable.  No need to keep a variable with such a generic name in global scope.

(Btw, you’ll notice that the check for existence of the console is different in #1 and #2. That’s on purpose.  Either works.)

3. Creating a custom wrapper for the console methods

This is probably my preference and it in a way combines the first two methods and takes them further by giving you more control.  I’m assuming that your site or project has a custom name space which encompasses all of your functionality and exposes only a single variable (object) in the global scope.  You can then assign a public property called debugMode which you could set to true (ex: using the Firebug console itself) to provide helpful output.

var myNamespace = (function(){

	var _self = {

		debugMode: false,

		log: function(msg){
			if (typeof console!="undefined" && console.log && debugMode){ console.log("myNamespace: " + msg); }

		doubleThisInt: function(someInt){ // some 'useful' method
			return someInt*2;

	return _self;

To make this more useful, you’d create custom wrappers for other console methods. A potential limitation of this approach is that there could be logs that happen as the page is loading and if the debugMode is set to false initially, you’d miss these as you wouldn’t have the opportunity to reset that flag.  To get around this you could use a slightly different version which uses a private debug variable (which also prevents your visitors from exposing your console messages), and accepts a hidden URL parameter which sets the debugMode flag on the server side.  For example, going to /mypage.jsp?someCrypticDebugParam=true or /mypage/debugMode/true would enable debugging and expose the log (and other output) as the page is loading and onward.

Auto stripping-out console calls for production use.

Some developers (often, the good ones) write build or deployment scripts which in addition to compressing or minifying the JavaScript code, also strip out all console calls for Production code.  I have a couple of issues with this.  First, this could mean that the code in your production environment is not the same as what you tested, or what you would be using when debugging.  And call me old-fashioned, but the idea of automatically stripping out code to this degree freaks me out a bit.  In any case, I’ve seen this done safely and don’t necessarily discourage the method.

A better approach, however, might be to assign blank methods to the console (see #2 above), regardless of whether or not console is defined, in Production environments.  This could be done safely by including a different JavaScript file which contains this version of the code during the build or deployment and therefore reduces the risk.  Though, here you’d preserve all debug code even though it never gets used which is not ideal and is not an issue when striping out that code.