One of the features of Firebug we like least has been the enable/disable stuff. Joe Hewiit’s original 1.0 Firebug had a pretty simple blacklist scheme for disabling Firebug sites; mostly users thought it was fine. But when users tried Firebug 1.1, the impact on performance of the eval() debugging features was too large, especially for users focusing on CSS or HTML. But the biggest problem wasn’t folks using any particular debugging feature, it was users of heavy AJAX apps like gmail.

For Firebug 1.2 we added more options to control what parts of Firebug were active. These enablement controls were hard to understand and very unpopular. But no one was willing to give up their favorite setting either. And at least you could blacklist gmail to reduce the pain of having Firebug installed in your browser.

Firebug 1.3 made some UI improvements that helped make the controls easier to learn. But the real innovation in 1.3 was the introduction of suspend/resume.  This was a global off/on switch which was simple and effective.I briefly experimemented with an ‘auto-suspend’ feature but could not get it to work before we closed 1.3.

In Firebug 1.4 we started with another round of fine-tuning. Then Steve Souders pushed for a more aggressively simplifed approach.

So for 1.4 we have ripped out all of the per-site controls and even the manual suspend/resume. Everything is now controlled by auto-suspend and the panels have only “enabled” or “disabled” settings.  In the new model, if you can see Firebug, then its active. If you can’t it’s not.

We hope and believe that the new solution will be very natural: you’ll open Firebug and start working. If you don’t want Firebug on a site, close it.  If you have Firebug open on a site and change tabs, Firebug will suspend. If you go back the the page you had Firebug open on, it will be open again and resumed.  If you really want to have Firebug running on a tab that’s not on top, open Firebug in a new window (so you can see it, then it’s active).

The Console, Script, and Net panels will be disabled by default when you first start Firebug. You can enable them if you need them; once you do enable them they will be enabled for all sites you open Firebug on. You can’t mix and match sites and panels like you could in 1.3, but we think this is a rarely used feature we can live without. There is one surprise: enabling the Console also enabled the Script panel. We hope to fix this in Firebug 1.5.

The new activation is in Firebug 1.4a14 if you want to give it a try.

Please post follows to the newsgroup.

I’m having deja vu all over again. Last spring we spent several months to get Firebug 1.2 to work on Firefox 3.0. This included completely re-writing the Firebug console and command line among other issues.   At the time I chalked this up to the big jump from FF 2.0 to FF 3.0. Now I can see this was the wrong way to look at it.

We are now trying to get Firebug 1.4 working on Firefox 3.5.  We’ve worked around two bugs,  484459 and 485055, and are only blocked by one at the present time (483672).  This does not seem so bad, except that we also have separate bug to fight with Firefox 3.0.7 (bug 482293) one that causes Firebug 1.3.3 to hang on pages with things like google maps.  We don’t have a resolution for this and our workaround in Firebug 1.3.4b2 breaks other things.

But if we step back and review our position, it’s not good. While we are spending time on new Firebug features and Firefox bugs, but we are not fixing existing Firebug bugs.   Moreover, debuggers should be available when systems are in alpha phase, but Firefox 3.5 is almost completely finished before Firebug can work with it.

So what can we do?

One option we cannot adopt is to develop Firebug on the Firefox trunk (now Firefox 3.6).  I’ve tried that in the past and it’s a nightmare. Firebug touches almost every part of Firefox so it almost never works on nightly builds for long. With Firefox 3.1 it wasn’t until b3 that enough stuff worked for us to start. Before that every effort to debug Firebug is a compounded by uncertainty in the underlying platform.

But we do have another option, based on three changes since last spring.  First, the Firefox team has been extraordinarily helpful with Firebug issues, once we are able to express a problem in Firefox terms.  Second we finally have a Firebug test system. And third, Honza and I can build Firefox now so we are better able to communicate our issues (which originate in Javascript)  to the Firefox team (which thinks primarily in C++).

So our plan is for Robcee to work towards automatically running the ‘passing’ Firebug Tests on the nightly trunk builds.  After we can succeed once, we hope that we can alert the Firefox team of problems that impact Firebug within a few days of their appearance, while the issues are still fresh in the developers heads. That way we can keep Firebug running rather than falling behind.

jjb

Ever couple of months I spend an embarrassingly long time tripping on the same stupid mistake:

win.addEventListener("pageshow", onPageShow,  true);
.. 2215 lines all twisted together...
win.removeEventListener("pageshow", onPageShow,  false);

The removeEventListener() call fails, silently, so the event handler can be called again. This symptom of the mistake can happen a long time from the error. The lines are so similar that it’s an easy mistake to make.  The dodgy documentation on Firefox events and trying to get Firebug working on FF3.1b3 provide lots of other explanations for the extra events one sees.

I really don’t get why the removeEventListener() does not give an error;  checking this would be a nice thing for a debugger to do (someday .

In the mean time I’m going to try a different approach: setting the capturing value on the event handler object:

win.addEventListener("pageshow", onPageShow,  onPageShow.capturing);
.. 2215 lines all twisted together...
win.removeEventListener("pageshow", onPageShow,  onPageShow.capturing);

That way they get changed in sync. Maybe you have another way?

jjb

While I still don’t get why Firefox is renumbering its next release to 3.5, the discussion did make me think about the Firebug version numbering. Our current user release is 1.3.3 which targets Firefox 3.0.4+.  Our next release is 1.4 and we will be targeting Firefox 3.5.  These Firebug major release numbers have very little information content. Firebug 1.n is just the n-th release since 1.0.

So what if we jump 1.4 up to 3.5 and then track the Firefox release nmber. That is, the Firebug major release number would just be the target Firefox release number: Firebug 3.5 is for Firefox 3.5; Firebug 3.6 is for Firefox 3.6.

If we have a major Firebug release more often than Firefox (as we plan to do), we’ll jump up the third number. So we might go from 3.5.1, 3.5.2, 3.5.3, then 3.5.10, 3.5.11, 3.5.12,  or 3.5.50, 3.5.51, 3.5.52, and so on.  These numbers would be for the addons.mozilla.org version; the getfirebug version would start with 3.5.0a1,  then when we freeze the features we’d start 3.5.0b1 until we are ready for amo at 3.5.0.

The cost is a one time renumbering and explanation, plus on-going cost of tracking Firefox numbers.  What I most dislike about renumbering is the feeling that we promised 1.4 and 1.5, but not we are not delivering, exactly. We want to provide a steady resource for users and extension developers, something they feel they can count on.  But the advantage of having our major release numbers match Firefox seems more valuable.

Thoughts?

jjb