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.

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.

(more...)

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.

Looking at my responses to my previous post, it seems pretty clear that a lot of people simply don't understand why companies stay on old technology. I have some other thoughts I'd like to give on Mozilla and enterprise, but before I do that, let's talk about the why.

(more...)

Update: I've done two other posts on this, Why Do Companies Stay on Old Technology? and Why Do Companies Need Time to Deploy Browsers?

This comment on my previous blog post from John Walicki is so important, everyone needs to see it.
(more...)

I've been writing a blog post about this in my head for a while, but after glazman's post, I definitely feel I need to weigh in.

My opinion of the new rapid release process depends on which hat I wear. So I'll offer three opinions.

(more...)

I've updated the CCK Wizard for Firefox 5 and placed it here.

The main change is that you can now explicitly specify the Firefox min and maxVersion when you create your XPI. It defaults to * for maxVersion so it will work on all future versions of Firefox.

So I've been thinking about add-on versioning for Firefox going forward and I'm starting to think that maybe it's being done backwards.

Right now we have to change either our add-on, an updateURL or AMO every time a new Firefox is released (every 6 weeks). Wouldn't it make more sense to mark an add-on as compatible with every future version of Firefox (maxVersion of *)? Then you'd only need to do anything if you realize your add-on is NOT compatible, not change something for every version of Firefox...

Thoughts?

Update:I just want to clarify when this method can be used. Obviously a web page can't update preferences in Firefox. We had a unique situation where a web page notified the browser of a change that allowed us to update a preference. It wasn't a lot of preferences. There is a lot of debate over having web pages message add-ons in this manner.

A few of the add-ons I've developed use web pages for their options rather than having them in a dialog. Unfortunately, when you use a regular web page as an optionsURL in your install manifest, it's opened up in a separate window that doesn't have scroll bars and doesn't work properly. Here's a workaround.

(more...)

I recently had the need to send a CSV file from my add-on to a PHP server and was looking for an easier way than constructing a POST request. I discovered that XMLHttpRequest has an API for this called sendAsBinary(). Using the API on the client side was easy, but figuring out how to get the file from PHP was a little tougher, so I thought I would share the information on my blog.

(more...)