Some users are confused by or object to the use of the [X] icon. Resolution : We understand the issue and we’ve implemented a plan, adding a glaring extra word — “Off” — to the UI and a new tooltip to warn users of the change in behavior of the icon.

Minimize does not stick. Resolution: actually there were a lot of related issues around minimize and the external window behavior; all we know about are fixed.

The only thing between here and 1.4.0 is uncertainty: did these recent fixes introduce more bugs? Are there bugs as yet unreported that impact many users most of the time? We don’t know the answers and we don’t have any way to find out. In the next day or so we’ll send out 1.4.0 and find out…

The 1.4 user interface design has many improvements. One improvement has caused some confusion as users of Firebug 1.3 try Firebug 1.4b: the Firebug window-control icons.

The controls from 1.4b are arranged to be consistent with operating systems windows. From the left the buttons are minimize, detach (so I can maximize), and close. For the developers and alpha testers, it seemed like the design was a step forward. It’s possible that some of the alpha testers were confused, but did not know if the problem was design or bugs.

But now look back at the 1.3 controls. There are just two, detach and hmm, well that [X] thing. By position and shape, the icon looks like the 1.4 ‘close’ but its implementation in 1.3 was 1.4 ‘minimize’. Naturally users expected the [X] button in 1.4 to minimize. When it closed they thought “arggh 1.4b is broken!”

So now we are in a jam: we can’t be consistent with both user expectations from 1.3 and normal practice.

Here is a proposed path out of this jam. Firebug 1.5a9 uses the same icons as 1.4b, but orders them like 1.3 and explicitly calls out the new one. So on the far right we have minimize like 1.3 but the button now looks like minimize. Next in the middle is detach aka maximize, also a new icon. Same position, new graphic. Then comes the troublesome [X] close icon. We want the same icon, different meaning. So, in addition to moving it out of the 1.3 position, we add explicit text, yelling to users that it means “off” not minimize.

Yes, this is a clunky solution and it’s not consistent with the visual order we want. But I propose we ship 1.4.0 with this clunky arrangement because it will dramatically improve the chances that users will understand the new meaning of the buttons. When 1.4.0 is released all current 1.3 users will be upgraded (if they accept it). Then at 1.4.1 we swap the order of the button, leaving the icons (and function) unchanged. Finally at 1.4.2, we lose the “Off” label.

Two foot notes:

The meaning of the icon [X] varies across and within applications. For example, in Firefox [X] on a tab closes the tab, the page is gone. But on say, the bookmark side bar, [X] means hide the UI but don’t stop managing bookmarks. From this perspective, both the 1.3 and 1.4 implementations of [X] are consistent with other applications.

In revisiting 1.3 to understand this issue, I was reminded of how clunky the 1.3 UI design is. I’m now more confident of our choices in 1.4.

We’ve had a lot of discussion on the newsgroup about Firebug 1.4. As with every new UI, we have a mix of documentation problems, design problems, and bugs. Here is my attempt to summarize the main problems, so folks know what I heard, as well as what I did not get.

Some users have “unstable” URLs: the site they are debugging has a constant domain, but variable URLs. Resolved: Implemented Activate Same Domain.

1.4 does not automatically reload, but 1.3 did. Resolution: need better documentation, may be add option to auto-reload.

Some users are confused by or object to the use of the [X] icon. Resolution: issues are still unclear to me.

Minimize does not stick. Resolution: see issue 1968. I’ll take a stab at a solution but no promises.

AJAX errors. Two pair: onDataAvailable+onStartRequest exceptions (Resolution: see issue 1879 fixed) and onreadystatecompleted+onsuccess no exceptions. (Resolution: see issue 1970. I’ve worked out a fix, but it’s not ready to commit).

CSS Edit problems. All of the symptoms are similar to issue 1894, but the reports keep coming. Some seem related to Show User Agent CSS. Resolution: still looking for a test case; may remove Show User Agent CSS option.

So this is my view of the major issues. I’ve left out a lot of complaints of the form “1.3 was better”, since we don’t have development resources to revisit the 1.4 design at this point. If I’ve missed some critical, show-stopping bugs or constructive suggestions on how 1.4 can be improved easily, please let me know.

We’ll go ahead with 1.4.0 this week, and next week we will pick up more localizations and bug fixes for 1.4.1. At that point I expect most activity will shift to 1.5.

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.

1.3.1b1 fixes a number of bugs found after 1.3.0 went up on addons.mozilla.org and includes even more locales. Bug fixes include the scope of the command line, various console or command line not ready problems, tab completion in the command line, and file locking.

1.3X.1b1, same as 1.3.1b1 but with FBTrace, the firebug tracing support to diagnose Firebug problems.

1.4.0a12 includes all of the bug fixes from 1.3.1b1 and more that could not be applied to 1.3 branch. In addition this release has a preliminary version of search-across multiple files contributed by the awesome kpdecker; we’ll probably have to back out some of the UI before 1.4b1 however.

1.4X.0a12, same as 1.4.0a12, but with FBTrace.

The 1.3.1 release mainly targets users affected by the bugs so we can get some feedback and see if we may have also resolved some issues without test cases but that sound similar to things we’ve fixed.

The 1.4.0 release is on target to be the best Firebug ever. And hopefully this alpha will make up for the unfortunate a11 release which had a number of problems.

Hello world! This is just a quick note describing this very blog you’re looking at. Its sole purpose in life is to provide a place for Firebug developers to leave feedback about what they’re working on, suggestions on how to better use Firebug or changes to internal APIs. I can also see this becoming a place to highlight new or popular Firebug extensions as they emerge or we learn about them.

As always, public discussion, feature requests and bug reports should go to the google code project page. Speaking of discussions, it’s fine to comment to individual posts here, but for meatier discussion to a potentially wider audience, traffic should be directed to the google group.