For those unaware, we have a review system that all new add-ons and add-on updates have to go through before they are available to the general public. The system is a combination of automatic code analysis and manual code and feature testing. The manual side is handled by a dedicated team of volunteers, known as AMO Editors. We’re a small group that has had to handle a massive amount of work, specially since the release of Firefox 3.5. We had spent the last year catching up with the numerous new submissions and updates, and the numbers will only grow once 3.6 is out.

Just 2 months ago, the new add-on review queue had over 600 pending add-ons, and the update queue had more than 250. Both had several months of waiting times, and add-on authors were increasingly unsatisfied, with good reason. Many trivial or important updates have had to wait a long time before seeing the public, causing users to complain and give add-ons bad reviews for the slow reaction of their authors.  That’s just unfair to add-on authors, and we needed a solution.

I joined Mozilla recently with a very clear objective: to reduce the review queues back to a manageable size. I have helped implement several solutions that would improve the state of affairs, like posting detailed weekly queue reports in the AMO forums, and temporarily hiring professional add-on developers to help with the burden. We estimate that our current volunteer team is large enough to keep up with the inflow, so now we just need to reduce queue size down to our ideal waiting expectations (2 weeks for nominations and 1 week for updates). After that I hope we will regain stability.

I’m happy to announce that our efforts have paid off. The latest queue report indicates that we’re down to 301 nominations, and 120 updates. That’s half of what we had 2 months ago! Just last month we reviewed over a thousand files, and our pace is increasing every week. About half of our pending reviews are within our ideal waiting time frames, and many of the ones that have been waiting for longer require an admin review for various reasons. Things are looking great.

There’s still lots to do in order to improve add-on author experience, and that is an ongoing effort. I’ve received quite a few suggestions on how to improve the reports, and I hope to implement those soon. If you’re a developer and you have anything else you’d like help with, don’t hesitate to contact me

ShareThis

My name is Jorge Villalobos, and I’m the new (first, really) Add-ons Developer Relations Lead at Mozilla. I’ll be working on bringing the add-on developer community and Mozilla closer together. I have been an add-on developer for over 2 years, working on around a dozen add-ons during that time. I’ve worked on a few independent projects as well, Fire.fm being the most successful one, and the one I’m most proud of.

My initial focus in this role at Mozilla is to reduce the add-on review waiting times to a point where authors can have some certainty that their add-ons will be reviewed within a reasonable time frame. The current state of the queues is far from ideal, with the recent release of Firefox 3.5 being a big contributor to the rising tide of submissions. The queues are long, and add-on authors are not happy. I actually have a somewhat important update for Fire.fm waiting in the update queue, and I can’t help but feel a bit impatient about it.

To solve the queue situation, we are working on several solutions. We’re constantly looking for and introducing new editors to our team. We are working more closely with them to understand how they work and what their concerns are, and also to focus their efforts in the areas that have the greatest needs. We are attacking the queue problem from several different angles, some which will help us in the short term, and some which are more forward-looking, such as the one I’m introducing here.

We want to change how we handle add-on reviews, specially for updates. Our current system doesn’t handle well the fact that there are add-on authors that no longer need to have the constant scrutiny of the editor team, and don’t need to have their updates reviewed every single time. We think we need to introduce a trust factor into the process, that allows us to give more freedom of publication to authors that have proven themselves trustworthy. There are plenty of those, and I bet they are the most active authors on AMO. Reducing the amount of update reviews we give to trusted authors will give more time to our editors to focus on new add-on nominations and other updates, significantly reducing waiting times and making everybody happy.

I also cover some ideas for reviewing add-ons that are not extensions, which usually have longer waiting times when in reality they should be the easiest to check.

If you’re interested in the details, please read the proposal on Google Docs: Review Process Redesign Proposal. It’s very short, so it shouldn’t take more than a couple of minutes to read. You can take part in the discussion of the proposal in the mozilla.dev.amo newsgroup, or post a comment here. I’ll try to respond to all as time permits.

ShareThis

Thanks!

ShareThis

Right now, Firefox 3.1b4pre is available as a maxVersion on AMO, and can be used by any add-ons that support current Shiretoko builds. On Tuesday, March 17, these builds will be renamed to 3.5b4pre, and the maxVersion on AMO will be renamed accordingly. This means that as an add-on developer, if you mark your add-on as compatible with 3.1b4pre before Tuesday, it will automatically change to support 3.5b4pre when necessary. After Tuesday, developers can simply start using 3.5b4pre as their maxVersion.

Similarly, Firefox 3.2a1pre will be renamed to 3.6a1pre on Tuesday. Any add-ons currently compatible with 3.2a1pre will automatically be 3.6a1pre compatible on Tuesday.

Followers of the add-on compatibility dashboard may notice that it will no longer be accurate after the renames on Tuesday. The AMO team is planning to support version grouping of Firefox 3.1 and 3.5 with its 5.0.4 release to be deployed on April 9.

Additional compatibility updates will be posted here on the Mozilla Add-ons Blog.

ShareThis

What we’re changing:

Based on a report on the dev-platform mailing list there are some interfaces that were changed between Gecko 1.8.0 and Gecko 1.9.0 without changing the IID for that interface.  Gecko 1.9.1, which inherited the code from Gecko 1.9.0, currently contains this error as well.  [Note that most of the discussion of the reported issue appears to be missing from Google Groups.  We are not sure why this is, but we assure you there was a long discussion of the issues.]

There are apparently some extensions for Thunderbird which need to be able to detect which version of an interface is being used based on the IID.  (Thunderbird 2 and Firefox 2 were both based on Gecko 1.8.0 and Thunderbird 3 and Firefox 3.1 will be based on Gecko 1.9.1.)  In order to make detecting that difference possible we need to make the change in the 1.9.1 branch before we release Firefox 3.1, as that will also serve as the baseline for Thunderbird 3.

These are the affected interfaces listed in the post and have been changed ahead of the release of Firefox 3.1 Beta 3:

475897 imgIContainer
475898 jsdIDebuggerService
475900 nsIAbDirectoryQueryArguments
475901 nsIAccessibleValue
475912 nsITokenDialogs
475913 nsIXULWindow
475915 nsPIWindowWatcher

These interfaces will be changed by the mailnews team before the release of Thunderbird 3:

475909 nsIMailtoUrl
475903 nsIFolderListener
475904 nsIImapMailFolderSink
475906 nsIImportMail nsIImportMailboxDescriptor
475907 nsINNTPNewsgroupList

Am I affected?

Very few people are likely affected by this change.  You might be affected if:

1. Your extension includes binary components written in C++ and uses the affected interfaces.
2. Your extension is loading an affected component using the IID instead of by name.

JavaScript-only extensions that refer to components by name instead of by IID will not be affected by this change.  This is almost all extensions.

What do I have to do if I’m affected?

If you’ve got an affected C++ component all you will have to do is rebuild your component with the new header files and re-release it.  We’re not changing interfaces, just the IID associated with them.

If you’ve got a component in JavaScript and you’re using interfaces by IID instead of name you will have to change the IID in your extension and re-release.

ShareThis

The most cumbersome part of this whole process is having to do a new build of your add-on just to change the maxVerison in install.rdf so you can test it out. Well, that’s not necessarily the case and while more experienced developers may know this, I want to ensure that contributors that are new to the Mozilla platform are aware that you can test your add-on in Fx 3.1b2 without having to physically update it.

All builds of Firefox allow you to turn off the add-on compatibility check which prevents unsupported add-ons from running in newer versions of the browser. By disabling this check, you’ll be able to install your add-on and run it through its paces. The process is painless and described below:

1. In your address bar, type the following: about:config

2. You may see a message that says, “This might void your warranty!”. Click on the “I’ll be careful…” button

3. Right click on any entry to display the context menu and select New > Boolean

4. Set the preference name to extensions.checkCompatibility and the value to false

5. You should now see the new entry listed

6. Finally, restart Firefox and install your add-on

Once you’ve tested your add-on, you can then decide how to best handle the maxVersion update. In many cases, if your add-on works perfectly and does not require any Fx 3.1-specific code changes, you can simply update the maxVersion via the developer tools on AMO.

If you find that your add-on isn’t working correctly, then that’s when you’ll need to correct any issues and upload a new version for review. The following page lists common issues that may cause your add-on to break:

https://developer.mozilla.org/En/Updating_extensions_for_Firefox_3.1

As Nick mentioned earlier, as of Fx 3.1b2, no changes are planned which should affect add-on compatibility so now is a great time to ensure you’re compliant and that your users will be able to continue to take advantage of your excellent work.

NOTE: Please be sure to set extensions.checkCompatibility back to “true” once you’re done testing. Otherwise, you’ll bypass checks during your normal browsing that could dramatically affect your experience. It should ONLY be set for testing your add-on and is not recommended for normal browser usage.

ShareThis

3.1 is coming!  We know that many add-on developers have held off on testing for 3.1 compatibility because they’re waiting for a near-final release to test against.  I’m happy to report that as of 3.1b2, no changes are planned which should affect add-on compatibility.  For those of you who migrate to 3.1b2, chances are extremely high that no further compatibility changes will be required for subsequent beta releases up to and including the final release.

Don’t hesitate!  With each subsequent beta, more people make the switch and having 3.1 compatibility will ensure a seamless upgrade experience for your users.

In many cases, your add-ons will work on 3.1 without any changes, so if you test and find this to be the case, simply update your add-on compatibility to 3.1b2 and it will automatically be recognized by Firefox during the startup version check.  If you do find that you’ll need to make code changes, we will prioritize 3.1 compatible extensions in the review queue to make sure that they are approved in a timely manner.

Finally, compatibility will be a requirement for any additions to our Featured and Category Recommended lists- so if you want to be considered for these lists, please make sure your add-ons work on 3.1.

Here are some useful links:

Download Firefox 3.1 Beta 2

Updating Extensions for Firefox 3.1

ShareThis

If you have tested and you are sure that your extension works with Firefox 3.1 beta 2 and doesn’t need any code update, just update the compatibilty version (3.1b2) on the AMO dashboard. This is enough.

If you know that you must update some code, do so and update the install.rdf file (increase the version of your extension and update maxVersion to 3.1b2), then upload your xpi file.

If you feel unsure about how to update your add-on, here are step by step instructions on how to update it. The following may sound very easy. That’s probably because it is easy.

1. First, download Firefox 3.1 beta 2 here:

http://www.mozilla.com/en-US/firefox/all-beta.html

2. Next, test your add-on:

Edit your install.rdf: if needed, update maxVersion to 3.1b2, and increase the version of your add-on.

Create a new Firefox profile:
firefox --createProfile testBeta2
Launch firefox with the new profile:
firefox -P testBeta2

Install your add-on.

Test your add-on thoroughly. Ensure that there’s no weird behavior or javascript errors.
We encourage you to set these preferences:
user_pref("javascript.options.strict", true);
user_pref("javascript.options.showInConsole", true);
in order to be notified about any javascript exception or warning.

If you run into issues, please check these common issues that may cause your add-on to break:
https://developer.mozilla.org/En/Updating_extensions_for_Firefox_3.1
Even if you think you won’t run into any problems, we still strongly recommend you read this page. You never know.

Then, make sure that your add-on works on your current profile (with all data already set by the last version).

3. Update your add-on on AMO:

If your add-on does not need any code update, just update the compatibilty version on the AMO dashboard.
if your add-on does need code update, then upload the new version to AMO.

That’s all!

Update your add-ons. It should be easy. If you run into issues during the migration or if you need some support, see our last post.

ShareThis

In order to help add-on authors migrate to Firefox 3.1, the Mozilla evangelism team is working on documenting changes between Firefox 3.0 and Firefox 3.1 which could affect extensions.

Some of you have already updated your extensions to Firefox 3.1 beta, or are in the process of doing so, and we’re asking for your help by providing some useful feedback about the migration.

We are interested in any issues you’ve encountered including interface changes, unanticipated behaviour or any API updates. You can provide feedback as a comment to this post and any information will help, even something as simple as:

“I ran into problems with interface XYZ”

Your assistance will be invaluable in helping us identify migration issues and ensuring that Firefox 3.1 has high rate of add-on compatibility upon release.

Thanks a lot.

ShareThis

The live version is up on addons.mozilla.org. Check it out!

ShareThis