Solving the Bugzilla Backlog

I've been doing a lot of complaining lately in directly violation of my first post of the year.

Going forward, I'm going to try harder to offer solutions instead of just doing a lot of complaining.

So, lately with Tyler Downer's post, there's been a lot of talk about Bugzilla and triage and other things. Yesterday, I was debugging a problem and discovered a bug that had been open for 5+ years with no fix (even though the component it was in had been rewritten in the mean time). (And before you ask, yes I posted a patch.)

The fact is that Bugzilla is a mess, not just with unconfirmed bugs, but with bugs that are no longer relevant, bugs that have already been fixed and more.

So here's my thought:

Stop all non critical activity on the Mozilla project for one week. All development, all test, etc. Have everyone in the community (and I mean everyone) attack Bugzilla and get it as cleaned up as possible. Have awards for the people that resolve the most bugs.

Thoughts?

Improving Stakeholder Communication in Firefox

As I've been watching this rapid release thing continue to unfold, I've been thinking about what it is that truly went wrong in the messaging. The fact that at this point, Mozilla executives are having to continue to try to sell this to people means that something went wrong in how they executed the change. As I thought about it more and more, I realized what a big part of the problem was - stakeholders.

Richlistbox Tricks for your Add-on

I've been messing around with richlistboxes a bit and I learned a couple of things, so I thought I would share.

The first thing I learned is that richlistboxes don't participate in layout the same way as a listbox, particularly in a (edit: tabbed panel in a dialog) dialog. If you dynamically add items to them, they will push other items off the dialog. (edit: Rows attribute should have never been in the richlistbox docs - I removed it)There's a "rows" attribute on the richlistbox that would seem to be for this, but it doesn't work. Most people probably just end up setting max-height or explicit height and width, but I don't like that. Here's what I came up with.

If you are going to dynamically add items to the listbox, set it to flex and then query the width and height during window load and explicitly set the width and height to be those values:

  var listbox = document.getElementById("myrichlistbox");
  var listboxStyle = window.getComputedStyle(listbox, null);
  var width = parseInt(listboxStyle.getPropertyValue("width"));
  var height = parseInt(listboxStyle.getPropertyValue("height"));
  listbox.setAttribute("width", width);
  listbox.setAttribute("height", height);

If you are adding items in the XUL using a template or being explicit, hide the richlistbox and put a vbox in its place. Then during load, query the size of the vbox, set those sizes to the rich listbox and hide the vbox/show the richlistbox.

The second thing I learned is that headers don't work properly in richlistboxes. Like me, you probably placed headers at the top of your richlistbox the same way you would for a listbox thinking, "It's a listbox, so listbox headers should work."But you might have noticed that when you scroll your richlistbox, the headers scroll away. Working around this was a little trickier. Come to find out, richlistboxes don't support headers properly. To fix it, I found the one place in Firefox that uses a richlistbox and has a header - the Applications tab in preferences. Here's the code:

<richlistbox>
  <listheader style="border: 0; padding: 0; -moz-appearance: none;">
    <treecol value="First Header"/>
    <treecol value="Second Header"/>
  </listheader>
</richlistbox>

The style stuff looks ugly, but it's to make it appear properly on Linux.

I hope these tips will save my fellow add-on developers some work.

Change is Expensive

Firefox Button

One of the statements that keeps getting thrown around in the discussion about the Firefox rapid release process is that because the releases are every six weeks, there isn't really enough time for any major changes. This statement is patently false, and there's an easy way to prove that - the Firefox button.

The Firefox button was a huge change for Firefox 4. I would wager it cost (or will cost) companies across the world tens of thousands of dollars (or more) in rewriting of support scripts, redoing of screen shots and actual support calls.

Let's assume for just a minute that the switch to the Firefox button had been done within the context of the rapid release cycle. How would it have happened? Could it have been phased in? Could it somehow have been done across multiple releases? No. The answer is that between two "minor" releases, the change would have simply been made. What's the takeaway?

Whether or not a change is major or minor has nothing to do with time. It only has to do with the change.

So how do you mitigate a situation like this? I'm glad you ask. You do what Microsoft did and provide a Group Policy (or preference) to turn on the menu bar by default. This allows the browser to be deployed without taking this change. I received quite a few emails when Firefox 4 was released with folks asking this specific question. I had to tell them that there was simply no easy way to do it in Firefox without writing an extension. I considered adding it into the CCK Wizard, but simply haven't had time.

We'll finish with a story. Last week my wife finally bit the bullet and upgraded from Firefox 3.6 to Firefox 4/5. She's technical and has been using web browsers for 10+ years. Her first comment? "Where did my menu go?" I said, "Everything is in the Firefox button now." She said, "I want my menu back." So I showed her how to get rid of the Firefox button and go back to the old menu.

You're messing with 10+ years of muscle memory here. Change is hard. And expensive.

Personas Interactive 1.2 with TweetTheme

I'm excited about the new version of Personas Interactive that Brand Thunder just released.

If you don't know, Personas Interactive builds on the Personas features in Firefox adding in things like multiple background images, Personas specific toolbars, galleries that can be hosted on any site and more. It removes the limitations of Personas.

This new version gives the user more control, including adding social network buttons to every theme and weather customized to your location.

But the coolest thing in it is support for our new TweetTheme. Combined with PI 1.2, TweetTheme gives you a full Twitter experience in your browser, including Twitter in sidebar, tweeting and searching Twitter from your toolbar, as well as a viewer that shows your last twenty tweets. It really shows off the power of Personas Interactive. I hope you'll try it out.

You can click here to install Personas Interactive with TweetTheme.

And you won't believe what Brand Thunder has coming up next. BT:Engage lets you build your own themes that will work with Personas Interactive. You can try it out now!

Firefox 4 Doesn't Recognize New Thawte Code Signing Cert

We just got a new code signing cert from Thawte and after getting it installed, I discovered that Firefox 4 would still show "Author not verified" when installing the XPI. After doing some research, I found this bug - Turn on the code signing trust bit for the Thawte Primary Root CA. It has some information on a workaround, but it wasn't very detailed so I thought I would post it for everyone.

Here's what I did:

Per the Thawte instructions, I use on IE on Windows to manage my certs. After importing my new cert into IE, the first step was to export it. Important: When you export the PFX file do NOT check the box to include all the certificates in the certification path.

Next, I created a new cert database using: certutil -N -d .

Then I imported my cert using pk12util: pk12util -i {filename}.pfx -d

Thawte has created a new intermediate cert to work around this problem. It can be downloaded here.

You need to download it and import it into your database using this command:

certutil -t "c,c,C" -n "thawte" -A -d .< new_thawte.cer

You should now be able to sign your XPI.

One other thing I ran into was finding a version of NSS that worked properly. I ended up using this one.

Creating a Universal updateURL

In the discussion of the Firefox rapid release process, one of the complaints has been that add-ons that are not hosted on addons.mozilla.org (AMO) don't get automatically bumped to be current with the latest Firefox. I needed to solve this problem for one of my clients, and here's what I came up with.

Why Do Companies Need Time to Deploy Browsers?

To be clear, I mean browsers that have some level of change to them BESIDES JUST SECURITY FIXES. When it comes to security fixes, I've seen companies deploy those changes immediately.

Throughout the discussion on my previous post, the focus has been on web applications and web compatibility. I thought I'd take some time to bring up all the other issues that go around deploying browsers in an organization.

There was a statement in John Walicki's comment that was missed by most:

Education programs, documentation updates, communications all are planned.

While these changes were between Firefox 3.6 and Firefox 4 which contained major visual updates, there is no promise that these "minor updates" won't include these kind of changes as well. And these changes require all of the internal documentation to be updated as well.

IBM has hundreds of support documents, including walk throughs, screen captures, webcasts, etc. that all reference the user interface of the browser. Every single one of these had to be redone for Firefox 4 (and probably done twice because Mac and Windows Firefox are so different now). And with the new release process, changes like these could happen with as little as 7 weeks to remedy the situation.

There's also the issue of training. As I said in my last post, many companies that use these browsers are NOT technology companies. So the assumption that users will figure out how to use the browser when it changes are simply wrong. When people see things they haven't seen before, or things don't work like they did before, they call support.

Repacking for deployment takes time as well. Most companies would not want an outside entity like Mozilla to deploy software to their machines. So they have to package and certify the application. A lot of changes are also staged, so just because the browser was released on a certain date doesn't mean it will make it down to the user's machine immediately.

There are probably lots of other issues that companies run into in trying to deploy software every six weeks. I'll leave that to other folks to talk about in the comments.