Summary
- These posts written every 2 weeks 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 that should be read as a general guide about the review process.
- Most nominations are being reviewed within 10 days.
- Most updates are being reviewed within 5 days.
The Review Queues
- The stats are taken from the current state of the queues. There was no queue report in the forum due to the New Year’s holidays.
- 124 nominations in the queue awaiting review.
- 94 updates in the queue awaiting review.
- 841 reviews were performed by AMO Editors last month.
See the Add-on Review Process and You for information on how to check your add-on status in the review queues. A significant portion of this process will change in a couple of weeks, when the new developer tools on AMO are pushed live. We will be blogging more about this when the time comes.
Firefox 4 Compatibility
Firefox 4 will be released very soon, beta 8 is currently available for download, and AMO already supports 4.0.* as a valid maxVersion. 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.
Beta 7 was the first release after the codebase went through feature freeze. This means that no major changes are going to be performed, and add-ons that work correctly on current betas are likely to work in the same way until the final release. Here are some pending issues of Firefox 4 compatibility that haven’t been addressed in other blog posts:
- Since toolbar buttons are very important for developers and button sizes changed for Firefox 4, I wrote this analysis of toolbar buttons and icons in Firefox 4. One problem was brought up in the comments, which triggered the creation of bug 616472. It has already been fixed at least for Mac, which now accepts 16×16 px icons, and there’s a proposal to provide an automatic filter that converts icons to monochrome, allowing authors to use the same graphic without the colors breaking the general look of Firefox on Mac. These changes should be testable on current Minefield builds and on the next beta release.
- The Add-on Bar is supposed to appear automatically when a button or other items are added to it. Bug 616419 was filed for this. It doesn’t look like it will be fixed soon, but an alternate solution is proposed in the comments.
- The requires tag in install.rdf will not be supported in Firefox 4.
- Firefox 4 no longer creates child HWNDs for internal use, which breaks a few binary add-ons and accessibility tools that relied on this quirk.
- Regarding the problems with Thread Manager and the lack of alternatives, I’ve had some useful conversations with Mozilla engineers, and we’re trying to reach a solution. I’ll be writing more about this in the following days.
- Addon object not passed to custom about dialogs. Fixing this will be very helpful for developers who have their own custom dialogs and don’t want to mess around with the asynchronous Add-on Manager API and the reflow problems that can arise from changing XUL content dynamically. The bug has a patch but it’s missing a test case. If you can add a test case for the patch, please post it on the bug.
- Many have asked what needs to be specified in the chrome.manifest file to support command lines in Firefox 4. Here’s what I’ve picked up by looking at other add-ons (CLASSID is your component’s class id and CATEGORY is the category used to register to the category manager):
component {CLASSID} components/mycmdlinehandler.js contract @mozilla.org/commandlinehandler/general-startup;1?type=mycmdswitch {CLASSID} category command-line-handler CATEGORY @mozilla.org/commandlinehandler/general-startup;1?type=mycmdswitch
Benjamin Smedberg wrote a post about reusing a Jetpack component to run JS code in a separate process. As it is now expected from any form of separate processing, there’s no XPCOM access and all communication happens through message passing. Actually, I don’t really know what’s the difference between this and ChromeWorkers. An explanation was posted by a developer a couple of weeks ago.
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. It’s currently being edited to adjust it to the upcoming review system.
- 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
Atte wrote on
Jorge wrote on
Tony Mechelynck wrote on
Jorge wrote on
S Sarkady wrote on
Jorge wrote on