Reception. Observation. Perception. Emotion.

Firebug Fail

LOLbugWhat’s up, all you savvy web developers? Question: do you enjoy using Firebug to make coding and debugging a blissful experience? Does it indeed make you feel warm and fuzzy inside? Well, good for you, because things are about to change. Turns out “awesome” wasn’t a good enough standard for the Firebug devs, so they’ve set out to fix what wasn’t broken and completely change the activation model, completely disposing of domain whitelisting and blacklisting. Ummm, thanks? Anyhow, I decided to voice my thoughts on the matter via the official Google Group:

This new “activation model” is patently insane and just made my life 100 times more difficult. If someone were to create a fork of Firebug 1.3 that preserved domain whitelisting/blacklisting, I would pay $50 for it easily. johnjbarton [the resident firebug developer], since you seem oblivious to how the new version is problematic, let me spell out some common scenarios I have tried:

Previously I enabled firebug for localhost, since that’s where I do most of my testing and developing. Then I would browse from page to page (without the panel open) until the “script error” message came up on the status bar. Then I’d open the firebug panel and troubleshoot. I’d fix it then perhaps browse around a few more pages, with the panel still open. When I was happy I’d solved the problem, I minimized firebug (back in those halcyon days, I could click the “x” button or the little firebug icon to remove the panel—it didn’t matter). But firebug stayed active, so I would be alerted to script errors if they happened.

Fast forward to today. Seems firebug now remembers panel position PER PAGE, which is ludicrously stupid. So as I browse from one page to the next, the panel is randomly disappearing and reappearing. And of course I can no longer simply tell firebug to be active only for localhost. WOW, WHAT SOME GREAT NEW FEATURES, GUYS!

The new system is completely absurd, and I hope now you can begin to see why. When a tool as ubiquitous as firebug gets changed so drastically, the question is WHY? We all loved it before, so please stop butchering it. And again, I put out the call to some developer out there who would want to continue the awesomeness of firebug 1.3 and perhaps rename it. That person would be regarded as a hero at this point…

I received an immediate response that at least acknowledged the legitimacy of my point of view:

Work on Firebug 1.4 is complete. Your scenario description is a good one, I wish we had it back when we were working on this feature. I’d love for Firebug to be perfect for everyone, but in every change there will be some winners and losers I guess.

The activation model in 1.4 was designed to allow extensions to provide special activation solutions.  If anyone wants to create one for this use case we’d be happy to give advice. (Just to set expectations, I have no plans to do any more work on activation myself).

As you can see, it seems this train is already moving at full speed, and those of us who loved the way Firebug formerly behaved will unfortunately have to endure (for the time being) the headache it has become. We can only hope a proper “extension” is released that brings back the wholly intuitive domain-based activation scheme that worked perfectly before. Until then, a single tear shall roll perpetually down my cheek.


  1. When you start your fork with just this single “activation model” fix in it, please let me know…

    Not having constant debug and console.log output (regardless of the state of my firebug panel) is fast becoming my greatest annoyance with this upgrade. That, and the lack of YSlow!…

  2. Agreed. I’m not sure if these guys hit their heads or something, but there’s something wrong with their thinking. Did they think I’d only want to see errors if the panel was open? Maybe in the next version they could require the panel to be full screen before logging anything…


Leave a Comment