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