• 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

• 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 7 days.
• Almost every update is being reviewed within 3 days.
• By the end of this month we expect all nominations to be reviewed in less than a week, and all updates in 3 days or less. We’re pretty much there.

The Review Queues

• The stats are taken from the latest queue report from last Friday.
• 35 new nominations that week. 37 nominations in the queue awaiting review.
• 22 updates that week. 24 updates in the queue awaiting review.
• 593 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.

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.
• 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. There are still some corrections to be made, and I’ll be blogging more about it later this week.
• 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

• 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 9 days.
• Almost every update is being reviewed within 5 days. We want to reduce this in the future, but nominations are the current priority.
• By the end of this month we expect all nominations to be reviewed in less than a week, and all updates in 3 days or less.

The Review Queues

• The stats are taken from the latest queue report from last Friday.
• 66 new nominations that week. 79 nominations in the queue awaiting review.
• 42 updates that week. 40 updates in the queue awaiting review.
• 111 reviews performed by AMO Editors this month, and 965 for the month of May. There were 16 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

• 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. There are still some corrections to be made, and I’ll be blogging more about it later this week.
• I made a proposal for the Google Summer of Code which has been accepted as a project. The idea consists in simplifying and refreshing the way add-ons are packaged and installed locally, including a completely new manifest file. In the past couple of weeks I have been blogging the spec proposal: Part 1, Part 2, Part 3. I’m now working on the wiki page that will be the actual specification for the project, that incorporates much of the feedback received so far. As the blog posts explain, this is not something that is intended to be included on Firefox. It’s an experiment on how we can do things differently, and hopefully (part of) it will be integrated into the product after more community feedback and polish.
• 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

• 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. Our goal is have them all under 1 week by July.
• Almost every update is being reviewed within 7 days. We want to reduce this in the future, but nominations are the current priority.

The Review Queues

• The stats are taken from the latest queue report from last Friday.
• 77 new nominations that week. 119 nominations in the queue awaiting review.
• 52 updates that week. 57 updates in the queue awaiting review.
• 627 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

• 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.
• I made a proposal for the Google Summer of Code which has been accepted as a project. The idea consists in simplifying and refreshing the way add-ons are packaged and installed locally, including a completely new manifest file. In the past couple of weeks I have been blogging the spec proposal: Part 1, Part 2, Part 3. I’m now working on the wiki page that will be the actual specification for the project, that incorporates much of the feedback received so far. As the blog posts explain, this is not something that is intended to be included on Firefox. It’s an experiment on how we can do things differently, and hopefully (part of) it will be integrated into the product after more community feedback and polish.
• 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 AMO, please make sure to file a bug (see note below about AMO bug reporting).
• Fennec (Firefox Mobile) is quickly approaching its 1.1 release, and add-on authors should make sure their Fennec add-ons are up to date in compatibility. 1.1.* is now a valid max version string for Fennec add-ons. Remember you can change your max version on AMO without having to upload a new file!
• 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

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.

Collections Phase II

We’ve had over 27,000 collections created and 6.5 million add-on downloads from those collections since the launch on June 10. We want to add a number of new collection features to the website and Add-on Collector extension, including:

• collection ratings
• statistics dashboard for collection creators
• add-on recommendations based on collection data
• recently viewed collections
• Thunderbird & Fennec support for the Add-on Collector

Check out this spec for all the details planned for this second phase. If you have feedback on this, please post it in this newsgroup thread. The website features above are included in AMO 5.0.9, which should be released at the end of next week.

Add-on Developer Hub

In May, we posted about our plans for a new one-stop-shop for add-on developers. Whether you’re someone new to Firefox and not sure if you want to write an extension, a long-time developer looking to stay up-to-date on add-on news and documentation, or an add-on author wanting to update your AMO listings, the Add-on Developer Hub at AMO will be the place to go.

Among the features of the new developer area are:

• add-on case studies
• AMO policies
• how-to library/portal
• API/Language reference links
• add-on builder (extension skeletons with working UI components)
• add-on validator

You can see some mock-ups of what the new site will look like here, or view the spec for all the details. Please post any feedback in this newsgroup thread. We’re planning this for AMO 5.1, which should be released in late September.

Disclosure of Add-on Practices

Many add-on authors, individuals and companies alike, invest large amounts of time and effort into their add-ons, and wish to be compensated for their work. Although we have launched the Contributions feature for authors to accept donations from users, some authors have partnered with companies to support the continued development of their add-on in exchange for the add-on making certain changes to Firefox. We enacted a No Surprises policy in an effort to protect user choice, but unfortunately continue to find surprises.

We feel it is necessary for users to know about certain add-on practices that an add-on employs prior to installation. These practices must be disclosed in a clear and consistent way across AMO. Our plan for this is described in this spec. Please post any feedback in this newsgroup thread.

Add-on Compatibility Reporter

New versions of Firefox are always in the works, and the lead-up to a final release can be hectic for both add-on developers and the AMO team as we try to encourage everyone to test and update their add-ons in the new version. We’ve come up with an idea for an Add-on Compatibility Reporter extension that would be bundled with alpha and beta builds of Firefox and facilitate add-on testing and reporting.

If you have add-ons installed that don’t work, you can report that to AMO. If you have incompatible add-ons installed that work fine, you can report that to us too. We’ll look at all the submitted reports and email developers when we think we know whether the add-on is compatible with that Firefox version, or if it’s not compatible and what problems users are having.

For all the details, you can read the spec. If you have feedback, please post in this newsgroup thread.

As you can see, we have a lot going on, including several projects not mentioned here. Stay tuned to the newsgroup and this blog for the latest on add-ons.

Today, the main feedback concerning the review and distribution process of add-ons is:

• developers feel it takes too long for add-ons to be reviewed, and
• users and developers want to receive updates to add-ons that they have installed that haven’t been reviewed yet

It’s important for us to balance our desire for all add-ons to be discoverable and easy to install with the need for security measures for add-ons that haven’t been reviewed yet.

After taking many of these issues into account, I’ve come up with a proposal for removing the public and sandbox classifications on the site and moving to a more flexible, comprehensive trust system based on everything we know about an add-on. If you’re interested in the review process and distribution of add-ons, please read the proposal and give us your feedback, preferably in this newsgroup thread.

The first week of collections blew away our goals for the launch, so I’d like to share some statistics from the last week. Add-on users have created more than 11,000 collections, comprising 140,000 instances of 3500 different add-ons. Of those collections, 6200 are listed publicly in the Collection Directory, while the others are private. We’ve served over 245,000 add-on downloads from collection view pages, not including downloads served from other pages accessed through collections.

The Add-on Collector has been very successful as well, with 46,000 downloads and about 19,000 Collectors in use. Users of the extension have created 2500 auto-publisher collections, which are collections automatically kept in sync with the add-ons that user has installed in Firefox. And hundreds of add-ons have been shared with friends through the Collector’s email sharing feature.

But the most rewarding measure of success so far has been hearing people say collections have helped them discover new add-ons, which was the primary goal of the project.

Because the response to collections has been so great, we’re going to keep adding new collections-related features and improvements over the next few months. We have a number of ideas for what features to implement, but need help from the community to identify which cool new collection features are most wanted. So, if you’re interested in the future of collections, head over to the newsgroup and let us know which of the proposed features you want to see.

Our eagle-eyed readers will notice a few things about this mockup:

• The look and feel of AMO has evolved.  We’re currently working on a redesign of the site to make it more user friendly and a better reflection of how add-ons are an essential part of the lives of many Firefox users.
• There’s a “Meet the Developer” section which takes users into a page where they can learn about why a developer created an add-on and where they plan on going next.
• Tags will be introduced in the near future, which will help our users and developers explore and classify add-ons.
• And last but not least, the suggested contribution is present on the add-on page.

The Meet the Developer link goes to the following page, which should help developers explain the work they’ve put into their add-on and what features the contributions will help drive.  Also, when users make contributions, they will be able to suggest additional features that they’d like to see. The information on this page, including bits like the average rating, will help users make an appropriate decision around contributing without feeling obligated to do so.

These updates will be available to all developers, not just ones who ask for financial support.  Developers will also have a variety of ways to present contributions, and we’ll use developer and user feedback to determine which ones remain available after the pilot- so view this as a first step in a long evolution towards the best solution.

A big thanks to the fine folks at Clearleft for helping us with the redesign as well to the many developers who gave us advice and feedback on this feature.  As always, please let us know what you think in the AMO Newsgroup or by posting a comment.

If you’re interested in participating in our pilot, please sign up.

developer.amo will be a site dedicated to add-on developers, rich with documentation, tutorials, and community involvement. With this site, we hope to:

• Give new developers a starting point for creating an add-on
• Give existing developers a place to stay up-to-date on add-on development news, plans, and features
• Make development easier with documentation, tutorials, and examples all in one place
• Build a community of add-on developers to promote an exchange of ideas

From this one site, it should be possible for someone brand new to Mozilla add-on development to:

• find out why they would want to build a Firefox extension by reading case studies
• see examples of how add-ons work
• learn how to make a basic extension, and how to build that extension out into what they want
• get support when they have questions
• upload their add-on to AMO and have it accepted the first time (because policies will be readily accessible and easy to understand)

We’ve come up with an initial featureset we think will go a long way towards improving the developer experience, but would like input from the community before we get started. You can see our list of initial ideas on our wiki.

If you have thoughts on these features or other ideas, please let us know on the AMO newsgroup.

Edit: There seems to be some confusion about the relationship of this proposed site to MDC. As described in the wiki page above, there will be no new documentation hosted on this site. Rather, it will aggregate/link to existing documentation available on MDC and other resources. Any new documentation written as part of this site will still be hosted on MDC. developer.AMO will serve as a portal between AMO and add-on documentation, of which many articles are available on MDC.