Two weeks ago I blogged about how someone had taken an add-on of mine that was in production and uploaded a derived version to https://addons.mozilla.org (AMO) without changing its ID. This means that because the AMO web site identifies add-ons by their ID, it would not allow me to upload my add-on. I tried to solve this problem by engineering a solution to change my add-on’s ID.

I thought this would work and even provided some sample code for my ideas in my previous blog entry; however, there were just too many problems to overcome.

The sample code might work if Firefox’s UI gave users a pleasant experience when an add-on’s automatic update facility installs an add-on with a different ID. (I’m not blaming Firefox here; it’s probably not a supported scenario.)

Instead this is what the user sees:

Compare this to what they should see:

Notice anything missing? 5 points if you said the "Restart Firefox" button. It’s pretty important.

"OK," I say, full of resolve, "let’s just create an update with the same ID that downloads the new version for them." Essentially, we use an update with the same ID to get around the problem laid out above, but all that update does is to download the newest version of the add-on automatically. Finally, it uninstalls itself and then restarts Firefox. Here’s what I envisioned for the user experience:

1. Joe Bloggs sees there’s an update for one of his extensions. Firefox guides him through the update process, at which point he sees the picture above to restart Firefox to complete his changes.
2. Joe clicks "Restart," and as soon as this intermediate version of the extension springs into action and downloads the newest version of the extension. Firefox doesn’t have time to show its windows again before the download completes, and Firefox is forced to restart by the intermediate extension.
3. Joe sees his windows and tabs being restored, and he has the newest version of your extension.

Unfortunately, it never quite worked out that well. This is closer to the end user experience:

1. Joe sees there’s an update for one of his extensions. Firefox guides him through the update process, at which point he sees the picture above to restart Firefox to complete his changes.
2. Joe clicks "Restart," and as soon as this intermediate version of the extension springs into action and downloads the newest version of the extension. Meanwhile, Joe sees his windows and tabs being restored. All of a sudden, all of his windows disappear.
3. Joe at this point could try and relaunch Firefox, but that wouldn’t work since Firefox is technically already restarted. If he waits long enough he’ll see Firefox return, but all of his windows and tabs have gone.

Whether these were technical limitations of Firefox itself or problems in my code I never confirmed. What I knew was that the investigation had cost a lot of time, and I was very nervous about deploying something that could potentially frustrate a large percentage of my user base.

Turns out I made the right call. Nick Nguyen, who was my liaison at AMO, allowed me to take over the extension that used my add-on’s ID. No more problems, and definitely no more hitting my head against a brick wall.

So if you have deployed an add-on publically, and you’re thinking of changing its ID, don’t do it. There’s a better way to achieve what you want.

The Situation

In early 2008 I wanted to upload NAMFox onto AMO for the reasons mentioned above, and because the server it was already hosted on wasn’t very reliable. I set up a new account and went through the process to upload my add-on, when I encountered an error saying that I didn’t have permission to upload the add-on.* At the time I thought it was because the ID of my extension (superfastoz@neoseeker.com) didn’t match the email I registered with. (This was not the case; read further….) I gave up on trying to host it at AMO and continued using the same server the product had always used.

…Until a year later, when after some significant code rewrites I decided to try my luck again with AMO. I got the same error message and decided to investigate further. This time I discovered that it was actually because an add-on with the same ID already existed on AMO. I certainly didn’t remember uploading it before, and the previous project owner professed that he didn’t upload it on AMO either. I began writing a piece of software to download all the add-ons on AMO and check their IDs for conflicts, but I figured it would be a much more efficient use of my time to enlist some at Mozilla for help.

Enter Nick Nguyen, who helped me figure out that another user had uploaded an add-on with the same ID as mine. I was a bit disappointed; then I figured out that someone had taken NAMFox back in 2007, amended it to work with GameFAQs instead of Neoseeker, and then uploaded it to AMO with the same ID. I was flabbergasted. I had wasted so many hours trying to get NAMFox onto AMO, only to find this. Unfortunately all Nick and I could do was to email the original developer of that account to see if he would be willing to relinquish ownership of the project. Unfortunately I can’t just take it over, even though there is currently no download on the page, nor have there ever been (0 total downloads since 2007). If we didn’t hear back from the developer in a couple of months, I could perhaps take over the project then.

Well…

1. We haven’t heard back from the developer, and it’s been about two weeks now.
2. A couple of months is such a long period to go without a release or an update, especially since the add-on enhances a web site which is prone to change (and break NAMFox) without notice.

There was another alternative—I should change the ID of my add-on. Then I could easily upload it to AMO for people to use. There are a couple of problems with this:

1. Firefox treats two different add-on files as the same add-on if they have the same ID and as two separate add-ons if they have different IDs. This means that if anyone who had the old NAMFox installed downloaded the new version with a different ID, their Firefox would have two instances of the add-on running, the old one and the new one.
2. The same problem occurs with automatic updates. I can tell Firefox to download this updated NAMFox with a new ID, but now the customers that download the updates will have two instances of the add-on running.

In theory there is a way around this limitation, but I haven’t tried it…

The (Tentative) Solution

DISCLAIMER: I have not used the following techniques/code when releasing my add-on into the wild, so you should be careful if you’re going to adopt it.

UPDATE: Don’t try this! My Findings

The great thing about Firefox is that you can control just about every part of the browser, including the add-ons that the users have installed. If you’re like me, you’re probably thinking you can use this to get around the two limitations I listed above. In fact, I believe we can.

We’ve already identified the two scenarios that users can get your add-on with a new ID: through a direct download and through automatic updates.

If a user doesn’t have your add-on installed already, then we can agree that there is no problem.

If a user does have your old add-on installed already, then the new add-on must recognize this and uninstall it. This action is required regardless of whether the user used automatic updates to install the new add-on.

Turns out this is actually quite simple and only requires a few lines of code:

This code exists in the new add-on; for me it runs in an event listener for the window’s load event. It tries to find the old add-on with a certain ID. If it exists, it’s uninstalled and Firefox is restarted to commit the change. When Firefox restarts, only the new add-on remains.

I’m planning to try this soon. I’ll update this post with the good, the bad, and the ugly after I do.

*The AMO team did a great job of cleaning this error message up. You’ll now see this message, which is much clearer.

The first step is obviously to download the extension, available at http://fireunit.org. I put a "Hello World"-type test together just to see the results. It should be no surprise that I saw the results in Firebug’s new Test panel when I opened the HTML page in Firefox.

So far so good. I noticed that FireUnit supported running tests from multiple HTML files, so I tried that based on what I found on the FireUnit examples wiki page.

I was a bit disappointed to see the following chrome error in Firebug when I ran this page:

What I should’ve done immediately was to download the source, but I was already sucked into hacking my local version to get it to work. I eventually did download the FireUnit source, but I still received errors like "nsHttpServer is not defined." (I tried to discover the cause of this problem, but after a couple hours of tweaking the httpd.js file, I decided to cut my losses and try something else.)

Not to be deterred (mainly because I really like the idea of FireUnit), I set out on writing an alternative to running test suites. What I created wasn’t pretty, but it was functional. I overwrote the fireunit.runTests function to take each argument and make a synchronous XMLHttpRequest for that specific page. Once I received the page, I would import all of the scripts on that page (i.e. importing the scripts in all of the script elements that had a src attribute). After all the scripts were imported, I would eval() the remaining inline scripts on the page which contained the tests themselves. Finally, I would repeat the process for the next test file, until all tests in all test files had run. It took a while to get this just right, but now I’m happy building tests instead of test infrastructure.

Another way I’m being unorthodox with FireUnit is that my tests are actually HTML files embedded in the add-on itself. This offers a few advantages over using a local HTML page but also comes with its own set of disadvantages. The main advantage is that I don’t have to deal with enabling the UniversalXPConnect privilege in every test function or (more importantly) the code I’m testing. The main disadvantage is that Firebug will not show the source for script files that exist in chrome (probably with good reason); perhaps this is just a Firebug preference that I’m missing.

Thoughts on FireUnit? I like what the extension aims to do and what it allows me to do already, albeit with some heavy tweaking. I know it’s in its early stages, but I can’t imagine that everyone would be willing to spend as much time as I did to set up the environment. On the other hand, it’s possible that not everyone will run into the same issues I did, especially with the nsHttpServer. I can’t think of much to improve besides making it much easier to run tests from multiple HTML files. About the only thing I would enjoy it would be great to see a QUnit-like HTML report for tests, with each module being a separate HTML file.

Now back to testing…