Add-ons Review Update – Week of 2010/08/17


  • 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:

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

3 responses

  1. Chris wrote on :

    I just completed the add-on marketplace survey. There hasn’t been any opportunity to leave comments, so here they are. Just want to let you know that I will quit using Firefox as soon as add-ons get pay ware. I don’t see by the way the sense in using a browser which let block you ads by an add-on, when this add-on is showing ads. And I don’t see any good in using a free browser whose advantage is to let you use add-ons, when the add-ons are not free. I used Firefox for many years, but there are alternatives.

  2. Jorge wrote on :

    @Chris: charging for add-ons or showing ads is the developers’ choice, not Mozilla’s. We’re expanding AMO to give developers the choice to charge if they want to. They’re not obligated to do so, and I believe the majority of add-ons will continue to be free of charge. Paid add-ons will have a difficult time competing with free add-ons, and I think only a few kinds of add-ons will make sense to be sold. One example are add-ons that rely on an external service that the developers need to pay hosting for.

    1. Paolo wrote on :

      Even if paid add-ons will still have a difficult time competing with free add-ons, creating a marketplace can only make competition easier for paid add-ons, and harder for free ones. Certainly not the opposite. This will shift the balance towards commercial goals, and also make the fact that people pay for the right to merely install a piece of software look as an encouraged practice on this Mozilla-hosted site.

      And for add-ons that rely on an external service that the developers need to pay hosting for, if the service is useful, then the end-user might as well register and pay for the service directly on the website that offers it. In that case it is likely that the service host will be the same entity as the add-on creator, but it may be encouraged to make the add-on open source to let people adapt the front-end to their needs, promoting a wider and better use of the paid service. And if the service is useful enough, then free add-ons to access it would be created in any case, returning to the scenario where there is no point in making the original add-on closed-source in the first place.