Since the beginning of AMO, we’ve had a set of featured add-ons that are displayed prominently on the homepage and an ever-expanding list of other areas. Being featured guarantees downloads and notoriety, and many add-ons, especially start-ups, see it as crucial in order for their add-on to succeed.

End users see this list as a safe place to start with add-ons and trust Mozilla to feature great add-ons that work perfectly. However the selection process until now has been a pretty objective one, handled randomly by a small number of people, and the list has not been updated as frequently as we would have hoped.

We would therefore like to reach out to the Mozilla community to be part of an Advisory board to review new add-ons, and maintain a set of featured add-ons that are updated each month. We think this is a fair, and novel way to overcome some of the hurdles involved outlined above, and a chance to hand the responsibility over to the community that actually use and develop add-ons on a daily basis.

The Featured add-ons advisory board

Every 6 months, a call will go out via the Add-ons Blog for volunteers to participate in choosing featured add-ons. Volunteers must commit to trying the add-ons that apply to be featured and attending a monthly conference call to discuss suitability.

Each Board’s term is 6 months and will be comprised of 5 community members and 2-3 members of the Mozilla Add-ons team.

A note on member requirements:

Members must abstain from voting on add-ons that they have any business or personal affiliations with, as well as direct competitors of any such add-ons. Members must be picked from the add-ons community: power users, developers, and evangelists of add-ons

If you would like to be considered for a position on the add-ons advisory board, please email amo-featured@mozilla.org with your name and contact details, no later than May 19th 23:59 PDT.

You can find our more about the new featured add-on selection process on the wiki.

• These posts written every 2 weeks explain the current state of add-on reviews and other information relevant to add-on developers.
• Nominations at the moment are being processed slower than usual. The new review system required hundreds of add-on developers to renominate their add-ons, which has placed a large workload on the editor team. Nominations are currently taking a week or two to review.
• Most updates are being reviewed within 5 days.
• Most preliminary reviews are being reviewed within 5 days.

The Review Queues

• These stats are taken from the last queue report. Preliminary queue stats are still pending.
• 59 new nominations that week. 161 nominations in the queue awaiting review.
• 80 new updates that week. 50 updates in the queue awaiting review.
• 2620 reviews were performed by AMO Editors in February (updated March 1st).

Firefox 4 Compatibility

Firefox 4 will be released very soon! Beta 12 is the current stable release and the first Release Candidate (and hopefully the final 4.0 release) should follow soon. AMO already supports 4.0.* as a valid maxVersion, and there are no major changes expected that affect add-on developers. If your add-on is already compatible, you should update your maxVersion to cover all future 4.0 releases. Most of the necessary documentation to upgrade your add-on for Firefox 4 is readily available:

• Firefox 4 for developers at MDC.
• Making your add-on compatible with Firefox 4.
• Firefox 4 Compatibility discussion in the Add-ons Forum. This is the best place to post any feedback and bugs related to Firefox 4 and add-on development.
• Toolbar buttons and icons for Firefox 4.

Notes for Developers

• If your add-on was recently disabled, it could be related to the mass sandbox cleanup we performed recently. You can still get your listing enabled again if you contact us. Your add-on page should have instructions on how to contact us.
• Add-on Performance at XUL School. This article is highly recommended to all developers. It explains a few methods to improve add-on performance, including how to easily measure startup times.
• The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process.
• Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla

One of the key goals of the new review system was to make AMO a safer place for our users. In the previous system, an add-on could be created, never submitted for code review, and still be permanently visible and searchable within the site. These add-ons had a couple different qualifiers along the years like “In Sandbox” and “Experimental”, and showed warnings indicating that were not safe to install. However, warning messages are prone to be ignored, and the mere fact of being listed on the official Mozilla Add-ons site was enough for some people to trust the code they were downloading and installing regardless of the warnings. We needed something different.

The new system requires all add-ons listed on our site to pass at least a basic security review, which we’re calling Preliminary Review. Add-ons that pass this review will be visible on the site but get lower rankings, and they have the “Experimental” qualifier near their install button. They also have automatic updates enabled, which is an advantage in comparison to the old sandbox system. All updates also have to pass our review process, either preliminary or full depending on what the developer chooses. There’s more info in the overview post.

Moving to the new system, however, requires a massive migration of add-ons that were previously in the sandbox. Since we can’t make decisions for our developers, we provided you with a choice: nominate your add-on for full review or preliminary review in the following weeks, or your add-on will be disabled. We have already processed more than 1500 nominations from add-ons that were previously in the sandbox, but there are over 6000 add-ons that remain to show any activity, even after 2 rounds of email notifications indicating the imminent deactivation of the add-on listings.

So, if you’re an add-on author and still haven’t nominated your previously sandboxed add-on for review, you have until the end of this week. Starting next week, your listing will be disabled. If you submitted a new add-on in the past month, or if you nominated your add-on but haven’t heard back from us, don’t worry. Your add-on should be pending review and we won’t disable any of those. The waiting times for nominations is pretty large these days (at least a couple of weeks) because of the migration to the new system.

If you have doubts about the status of your add-on, you can check it out following these directions:

1. Go to your Add-ons Page. It should show an overview of all your add-ons and their status.
2. For details about a specific add-on of yours, click on the Edit Listing link.
3. On the menu on the left-hand side, choose Manage Status & Versions.

If you’re still unsure, you can send a message to amo-editors AT mozilla DOT org, or visit the #addons IRC channel. We’ll be happy to help.

By the way, this post doesn’t cover Personas because they have a separate review process.

Submitting Your Add-on

Did you create an add-on you want to host on AMO (addons.mozilla.org)? Just visit the AMO Developer Hub to get started. You’ll need an AMO account and you should probably take some time to read our submission policies. We also have a detailed guide that explains what we look for when reviewing your submissions and deciding if and how it should be listed on the site.

When you submit a new add-on, you will have to choose between 2 review tracks: Full Review and Preliminary Review.

For the Full Review track, our reviewers will check that your add-on is safe to use, respects users’ privacy and choices, doesn’t conflict with other add-ons or break existing Firefox features, is easy to use, and is worth publishing to a general audience. While this appears to set a very high admission threshold, it really doesn’t; our goal is to publish as many add-ons as possible, while offering safe and useful choices to our users. Add-ons that receive Full Review approval will appear as Public, have the option to be Featured, can enable Contributions, and in general get much more public attention and downloads.

The Preliminary Review track only requires your add-on to be safe to use. Reviewers look for issues that could put the users’ system or data at risk. Add-ons with Preliminary Review approval appear on the site as Experimental, can’t be featured, and get lower search rankings. Like Public add-ons, they have automatic updates enabled.

So, why would anybody choose Preliminary Review? Many authors have expressed to us the need to host their add-ons on AMO in an intermediate state where they don’t get as much visibility and don’t have their add-ons as heavily scrutinized as they are for Full Review. Also, it serves as a replacement for the sandbox that we had in the previous review system. Now, if an add-on doesn’t pass Full Review, it can still qualify for Preliminary Review if it passes the basic security checks that we do. That will at least allow the add-on to be visible, installable and updatable.

Add-ons that don’t pass Preliminary Review are considered unsafe and are not published on AMO at all.

When your add-on is reviewed, you should receive and email message form us explaining if the review was approved or not, and what kind of approval you got. The message should include notes from the reviewer explaining what was discovered during the review and any issues that need to be addressed. Make sure that your registered email address on AMO is active and that you check on it frequently. On occasion we’ve been told that review email end up in the Spam or Junk folders, so you may want to check there if you think you should have heard from us by then.

Changing tracks

If your add-on has been approved in the Preliminary Review track, you can nominate it to the Full Review track after a 10 day waiting period. The 10 days begin from the time of your last Preliminary approval. After that you should see a Full Review nomination option in the Status & Versions page in the Developer Hub.

Updating your add-on

You can upload updates for your add-on from the Status & Versions page in Developer Hub. All updates are reviewed as well, and they will receive Full Review or Preliminary Review depending on the review track your add-on is in. If your first submission wasn’t reviewed before you uploaded the update, the new version will take its place in the review process.

Updates for add-ons in the Full Review track that don’t pass Full Review can still get Preliminary Review approval if any issues are found in the submission. In this case, the update will not be pushed to users, but it will still be visible and installable in the All Versions page of the add-on. The add-on remains in the Full Review track, and a fixed version needs to be submitted before updates can be pushed to users.

Update reviews are normally very fast (under 5 days), but we understand sometimes an update needs to be pushed as quickly as possible. Security fixes and broken external dependencies are the most common reasons for requesting this. In those cases you should contact the AMO Editors directly via email or IRC, and state your case. We can normally respond within a few hours.

The Review Queues

We have 3 lines where all review submissions are queued: one for Full Review nominations, one for Full Review updates, and one for Preliminary Reviews (both nominations and updates).

The waiting times for these queues can often vary, but our goal is to process all updates and preliminary reviews within a couple of days, and Full Review nominations within 10 days. I post queue state updates every week in the Add-ons Forum if you’re interested.

At this moment we’re doing very well on all queues except for Full Review nominations. We have a very large amount of reviews to process caused by the transition from the old review system to the new one, since thousands of old add-ons that never passed our reviewed process now require to do so in order to live on AMO. We expect to bring that queue back to normal within a few weeks, though.

AMO Editors

The Mozilla add-on review team is called AMO Editors. It’s composed mostly of volunteers; experienced add-on developers who take time from their busy lives to ensure the add-ons we list are good to use. Reviewing add-ons is a meticulous and often monotonous task, and many of them spend several hours a week working on this for free.

Reviewing add-ons for AMO is no small feat. Just last month the editor team performed over 2400 reviews. While these are exceptional times because of the release of Firefox 4 and the launch of the new review process, the average monthly review count usually hovers around 1000 reviews. With hundreds of submissions pouring in every week, there’s always work to do. So, if you run into an AMO Editor, give him a hug, or buy him a beer .

Questions and comments welcome, as always.

• These bi-weekly posts explain the current state of add-on reviews and other information relevant to add-on developers. There’s a lengthy overview of the Add-on Review Process posted in this blog that should be read as a general guide about the review process.
• Most nominations are being reviewed within 5 days.
• All updates are being reviewed within 5 days.

The Review Queues

• The stats are taken from the latest report at the forum (the 5th of November).
• 69 nominations in the queue awaiting review.
• 78 updates in the queue awaiting review.
• 177 reviews performed by AMO Editors this month. There were 14 editors performing reviews last week.

See the Add-on Review Process and You for information on how to check your  add-on status.

Firefox 4 Compatibility

Firefox 4 is coming later this year, and beta 6 is currently available for download. This will be the most difficult upgrade path for add-on developers yet, so everybody should keep an eye on beta updates and all the documentation that is being published. At the moment these are the most useful documentation resources:

• Firefox 4 for developers at MDC.
• Firefox 4 Compatibility blog post (Beta 4 edition!).
• Firefox 4 Compatibility discussion in the Add-ons Forum. This is the best place to post any feedback, bugs or insight surrounding Firefox 4 and add-on development.

Beta 7 is the first release after the codebase has gone through feature freeze. This means that after this release, no major changes are going to be performed, and add-ons that work correctly on beta 7 are very likely to work in the same way until the final release. After beta 7 is out (probably later this week),  I will be posting a very extensive view of Firefox 4 compatibility issues, including all that I’ve mentioned in previous posts. We will also be contacting all developers that have add-ons compatible with 3.6 and Firefox 4 betas, letting everybody know that they should be updating their code and Firefox 4 final is around the corner.

Notes for Developers

• Add-on Performance at XUL School. This article is highly recommended to all developers. It explains a few methods to improve add-on performance, including how to easily measure startup times.
• The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process.
• Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla

• These bi-weekly posts explain the current state of add-on reviews and other information relevant to add-on developers. There’s a lengthy overview of the Add-on Review Process posted in this blog that should be read as a general guide about the review process. I’ve skipped  the last couple of updates due to a long vacation. Sorry for the interruption.
• Most nominations are being reviewed within 2 weeks.
• Most updates are being reviewed within 5 days.

The Review Queues

• The stats are taken from the current queues, since last week I didn’t post a queue report in the forum.
• 96 nominations in the queue awaiting review.
• 45 updates in the queue awaiting review.
• 621 reviews performed by AMO Editors this month. There were 9 editors performing reviews last week.

See the Add-on Review Process and You for information on how to check your  add-on status.

Firefox 4 Compatibility

Firefox 4 is coming later this year, and beta 6 is currently available for download. This will be the most difficult upgrade path for add-on yet, so everybody should keep an eye on beta updates and all the documentation that is being published. At the moment these are the most useful documentation resources:

• Firefox 4 for developers at MDC.
• Firefox 4 Compatibility blog post (Beta 4 edition!).
• Firefox 4 Compatibility discussion in the Add-ons Forum. This is the best place to post any feedback, bugs or insight surrounding Firefox 4 and add-on development.

Beta 7 is the first release after the codebase has gone through feature freeze. This means that after this release, no major changes are going to be performed, and add-ons that work correctly on beta 7 are very likely to work in the same way until the final release. After beta 7 is out,  I will be posting a very extensive view of Firefox 4 compatibility issues, including all that I’ve mentioned in previous posts. We will also be contacting all developers that have add-ons compatible with 3.6 and Firefox 4 betas, letting everybody know that they should be updating their code and Firefox 4 final is around the corner.

Notes for Developers

• Add-on Performance at XUL School. This article is highly recommended to all developers. It explains a few methods to improve add-on performance, including how to easily measure startup times.
• The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process.
• Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla

• These bi-weekly posts explain the current state of add-on reviews and other information relevant to add-on developers. There’s a lengthy overview of the Add-on Review Process posted in this blog that should be read as a general guide about the review process.
• Most nominations are being reviewed within 1 week.
• Almost every update is being reviewed within 5 days.

The Review Queues

• The stats are taken from the latest queue report from last Friday.
• 54 new nominations that week. 75 nominations in the queue awaiting review.
• 60 updates that week. 55 updates in the queue awaiting review.
• 864 reviews performed by AMO Editors this month. There were 18 editors performing reviews last week.

See the Add-on Review Process and You for information on how to check your  add-on status.

Firefox 4 Compatibility

Firefox 4 is coming later this year, and beta 3 is currently available for download. This will likely be the most difficult upgrade path for add-on developers in the history of Firefox, so everybody should keep an eye on beta updates and all the documentation that will be published around them. At the moment these are the most useful documentation resources:

• Firefox 4 for developers at MDC.
• Firefox 4 Compatibility blog post (New, beta 4 edition!).
• Firefox 4 Compatibility discussion in the Add-ons Forum. This is the best place to post any feedback, bugs or insight surrounding Firefox 4 and add-on development.

I’ll do my best to keep everybody up to date with breaking changes in Firefox 4, and I will post a new compat update when we’re closer to RC1. In the interim I’ll use these reports to post all the new (sometimes unconfirmed) feedback I’ve received, with as much information I have at hand. Here are the notes I have so far:

• Toolbar customization. There’s a bug in toolbar customization that can revert changes performed by users. Note that the bug can be triggered by add-ons that access certain browser features before the onload event is fired. If this is the case for your add-on, please read the comments on the linked bug carefully.
• From Mook: How do I override a contract ID dynamically, and forwarding things to the old implementation (essentially wrapping it) so only behaviour I specifically care about get modified? Is this something that the new XPCOM registration method won’t support?
• From Christopher Finke: app tabs can be toggled using gBrowser.pinTab(tab);
• From Raphael: the content context menu is broken.

Notes for Developers

• How to Improve Extension Startup Performance. All extension developers should read this blog post. It explains how extensions can have a significant impact in startup performance and, some very simple steps you can follow to minimize this impact. There’s also a link to some tools that can be used to easily measure startup.
• New Proposal for Review Process and Delightful Add-ons. This is a new and different approach to resolve the issue of add-on safety in the sandbox and code reviews. All add-on developers should read this and give feedback. It’s been a long process to try to find the right balance of the many elements involved, and we think this is it.
• The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process.
• Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla

• These bi-weekly posts explain the current state of add-on reviews and other information relevant to add-on developers. There’s a lengthy overview of the Add-on Review Process posted in this blog that should be read as a general guide about the review process.
• Most nominations are being reviewed within 2 weeks.
• Almost every update is being reviewed within 1 week.
• The Mozilla Summit and the Firefox 4 beta launches have delayed reviews noticeably, but we’re catching up.

The Review Queues

• The stats are taken from the latest queue report from last Friday.
• 42 new nominations that week. 128 nominations in the queue awaiting review.
• 60 updates that week. 80 updates in the queue awaiting review.
• 256 reviews performed by AMO Editors this month. There were 13 editors performing reviews last week.

See the Add-on Review Process and You for information on how to check your  add-on status.

Firefox 4 Compatibility

Firefox 4 is coming later this year, and beta 3 is currently available for download. This will likely be the most difficult upgrade path for add-on developers in the history of Firefox, so everybody should keep an eye on beta updates and all the documentation that will be published around them. At the moment these are the most useful documentation resources:

• Firefox 4 for developers at MDC.
• Firefox 4 Compatibility blog post.
• Firefox 4 Compatibility discussion in the Add-ons Forum. This is the best place to post any feedback, bugs or insight surrounding Firefox 4 and add-on development.

I’ll do my best to keep everybody up to date with breaking changes in Firefox 4, but I don’t want to bombard you with information. I will post a new extensive update after beta 4 is out later this month. In the interim I’ll use these reports to post all the new (sometimes unconfirmed) feedback I’ve received, with as much information I have at hand. Here are the notes I have so far:

• Toolbar buttons have different dimensions. Toolbar buttons now have a different look and a different size at least on Mac and Windows, but it is unclear if they will remain this way. Michael Kaply filed a bug about it and there’s an ongoing discussion happening over there. Like I mention in the Firefox 4 Compatibility blog post, the UI is the most volatile part in the 4.0 update, so it is not a good idea to rely on how it is in its current state. If you want your toolbar icons to look right in current betas without spending too much time, you’ll need some CSS trickery. Chrome manifest flags are very useful for these kinds of hack.
• Toolbar customization. There’s a bug in toolbar customization that can revert changes performed by users. There’s also an empty bar that appears under the toolbars after customization at least on Mac OS. Note that the bug can be triggered by add-ons that access certain browser features before the onload event is fired. If this is the case for your add-on, please read the comments on the linked bug carefully.
• xpcnativewrappers=no going away. This practice has always been considered unsafe, and there are safer alternatives for it. The post doesn’t mention that this will happen for Firefox 4, but the bug has a patch that is already approved, so it’s likely to happen soon.
• Details on the App button. If you have an add-on that relies on the main menu, keep in mind that the classic menu can still be toggled with the Alt key, but most of the time you’ll only see the App button (on Windows, at least). I’ve been told that the new place to overlay your menus in this menu will be under the Exit menu item. This is still changing, so don’t take my word for it.
• From Mook: How do I override a contract ID dynamically, and forwarding things to the old implementation (essentially wrapping it) so only behaviour I specifically care about get modified? Is this something that the new XPCOM registration method won’t support?
• From Christopher Finke: app tabs can be toggled using gBrowser.pinTab(tab);
• The new Gecko SDK is still not available in the MDC page. Developers that use binary XPCOM have to build it themselves from source. The source code for beta releases is available on the FTP site.
• From Matthew Wilson: after being deprecated for a while, the nsIPref interface has been removed.
• From Jason Barnabe: command line options on the new XPCOM registration system are currently undocumented.
• From Raphael: the content context menu is broken.

Notes for Developers

• How to Improve Extension Startup Performance. All extension developers should read this blog post. It explains how extensions can have a significant impact in startup performance and, some very simple steps you can follow to minimize this impact. There’s also a link to some tools that can be used to easily measure startup.
• New Proposal for Review Process and Delightful Add-ons. This is a new and different approach to resolve the issue of add-on safety in the sandbox and code reviews. All add-on developers should read this and give feedback. It’s been a long process to try to find the right balance of the many elements involved, and we think this is it.
• The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process.
• Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla

First of all, MDC is your friend: Firefox 4 for developers. This is the document that will and should have all the necessary information for web developers and add-on developers surrounding Firefox 4. Make sure you visit this document regularly and look for changes. If you know of anything missing in that document, please add it yourself or let us know.

Here are some highlights from the document.

The new Add-on Manager object

The nsIExtensionManager interface is no more, along with its RDF backend. Add-on data will now be stored in a SQLite database, and the Add-on Manager is now a JS Module called AddonManager.

A key difference in this new interface is that requesting add-on data is now asynchronous. This applies to the FUEL library as well, so every add-on that requests add-on data is affected. This is particularly delicate for add-ons that have to fetch and deal with this data at startup. However, if you’re also trying to follow our startup performance recommendations, you should already be planning on implementing an asynchronous startup process.

XPCOM Registration

There’s a lot going on in this area: XPCOM Changes in Gecko 2.0, and none of your components will work until you adjust to these changes.

Components now need to be explicitly declared in the chrome.manifest file. A number of startup observer topics have been removed, leaving only the one that has always been recommended: profile-after-change. Listeners and category registrations also need to be declared in the manifest and, because of this, some category names have changed.

Changes to tabbrowser

The TabClose, TabSelect and TabOpen events no longer bubble up to the tabbrowser element, also known as gBrowser. Event listeners for these events should be added to gBrowser.tabContainer.

Remote XUL is going away

Remote XUL is a rarely used feature in Gecko browsers that allow developers to create websites using XUL instead of HTML. Since XUL support is limited to a few browsers, it didn’t make much sense to create websites with it. However, it has been used successfully in a small number of internal business applications (also known as ‘dark matter’).

Remote XUL has been a big maintenance problem, and it has been the source for numerous bugs and security problems. For this, remote XUL will be removed in Firefox 4. Luckily, HTML 5 already includes a fairly robust box model, so the main loss here is that web developers will not be able to use XBL anymore. If you’re wondering what happened with XBL 2, removing remote XUL is a necessary step to work towards implementing it.

Theme and UI changes

This is an area where you need to check back frequently, because there are many ambitious plans for the Firefox 4 UI. Whether some of these changes will be implemented or not depends on time and finding the right compromises.

The main document for these UI changes is in the Mozilla wiki: UX Priorities for Firefox 3.7. Some important changes you should know about:

• Tabs on top. There will be a preference that controls the location of the tab strip and toolbars.
• App menu. On Windows (at least?), there will be a single menu button instead of the full menu toolbar. Pressing the Alt key will toggle the “classic” menu. This will surely have an impact on add-ons that overlay menus in the Main Menu.
• Home tab. This is a fixed tab in the first position of the tab strip.
• App tabs. It will be possible to toggle tabs into app tabs, which basically means they can’t be easily closed and their titles will be hidden, only showing the favicon. More interesting changes, like hiding toolbars for these tabs, are being planned.
• There are talks around hiding or completely removing the statusbar, another significant change for add-on developers. The discussion has spanned a number of blog posts, and will surely continue. For more information, please read parts 1, 2 and 3.

Other Stuff

• For performance reasons, Firefox 4 is now caching some resources more aggressively, including extension chrome and JS files. This can lead to unexpected behavior when developing an add-on because changes to some files will not apply unless the corresponding cache files are deleted. This is the relevant bug. Please don’t comment on it just to show support for either side; there’s too much of that already. In a nutshell, you should make sure that you have all the right preferences set and you use the -purgecaches command line argument when running your development profile. This will still fail to update your JS Modules, but this should be fixed in a future build.
• User Agent strings are going to be minimized for various reasons. In order to align with these efforts, AMO Editors will soon be looking for UA manipulation in extensions. We will forbid any unnecessary modifications. Unless your add-on really needs to change the UA, you should start removing this code.
• I was informed by a developer that dropping a URL into the sidebar now has the default behavior of trying to open this URL. If you handle drag and drop in your sidebar, make sure you use preventDefault.

As you can see, there’s plenty of work to do in order to become compatible with Firefox 4, so this is a good time to begin. However, keep in mind that Firefox 4 is still very much a work in progress, and there are likely more changes to come. Don’t think that you can create a final version of your add-on for Firefox 4 just based on the first beta. My recommendation is that you take your time and make sure you stay up to date with Firefox 4 news.

And, of course, there’s plenty of good stuff coming that will enable you to do amazing things in your add-on, including 2D and 3D animation, multi-threading and interaction with system libraries. Firefox 4 for developers is, again, your friend. The Hacks blog also has a nice overview.

Update: the second installment of this series was published a few days ago.

• These bi-weekly posts explain the current state of add-on reviews and other information relevant to add-on developers. There’s a lengthy overview of the Add-on Review Process posted in this blog that should be read as a general guide about the review process.
• Most nominations are being reviewed within 2 weeks.
• Almost every update is being reviewed within 1 week.
• The Mozilla Summit invited the most active contributors in the AMO Editors team. It was great and also very productive to meet them finally in person, but the review queues suffered noticeably because of that week we lost. It also didn’t help that Firefox 4 beta 1 was released just a day or two before the Summit. Major version releases trigger an unusually large number of new submissions and updates.  We’re catching up at the moment, but things will be slow for at least a couple of weeks.

The Review Queues

• The stats are taken from the latest queue report from last Friday.
• 50 new nominations that week. 129 nominations in the queue awaiting review.
• 100 updates that week. 101 updates in the queue awaiting review.
• 317 reviews performed by AMO Editors this month. There were 15 editors performing reviews last week.

See the Add-on Review Process and You for information on how to check your  add-on status.

Notes for Developers

• How to Improve Extension Startup Performance. All extension developers should read this blog post. It explains how extensions can have a significant impact in startup performance and, some very simple steps you can follow to minimize this impact. There’s also a link to some tools that can be used to easily measure startup.
• Firefox 4 is coming, and with it there are a number of platform changes that will need to be addressed by extension authors. We will increase communication as the launch date becomes clearer, but in the meantime, you should be aware of these: Add-ons Manager with Asynchronous API, Changes in XPCOM, Remote XUL to be Removed,  JSM can now be included in chrome JARs. A more detailed post will be published in this blog later this week.
• New Proposal for Review Process and Delightful Add-ons. This is a new and different approach to resolve the issue of add-on safety in the sandbox and code reviews. All add-on developers should read this and give feedback. It’s been a long process to try to find the right balance of the many elements involved, and we think this is it.
• The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process.
• AMO is currently being migrated to a new code base, some of which is already live in production. If you notice any strange behavior on the site , please make sure to file a bug (see note below about AMO bug reporting).
• Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.
• Bugzilla information for editors. How to file AMO bugs, how to flag bugs relevant for editors, and information on current and future AMO version releases. Let me know if you want to help fixing AMO bugs.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla