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.

Highlights

• An entirely new design provides easier access to commonly used features, such as updating compatibility information, and much better interactions for add-on submission and management.
• The new review process ensures all add-ons hosted on AMO are safe, while still allowing developers to distribute their experimental work and receive feedback.
• Our add-on validator is much smarter than before and will provide helpful analysis to developers and editors.
• Add-ons now have slugs, which make URLs easier to read. (example)

New Review Process

We want the thousands of add-ons available in our gallery to be safe for users to install, so early last year we set out to find a solution to the thousands of unreviewed add-ons living in our “sandbox”. We wanted add-ons to be reviewed in a way that would also allow developers to upload and distribute their work quickly in order to receive feedback from our community of add-on fans always looking to try new things.

After several proposals and discussions with add-on developers, we came up with the concept of preliminary review, which is a lighter review that only checks for security issues. These reviews are much faster than full reviews and may still contain functional bugs and policy violations, but should be safe to use. Developers will now be able to choose a review process at submission, and while they’re waiting for review, can blog or share the direct link to their add-on.

Anyone interested in learning more about the new review process should read our updated Review Process Policy page. Authors of add-ons currently in the sandbox will receive an email next week with instructions on how to continue hosting their add-on in our gallery. The only change authors of “public” add-ons should see is that they are now called “fully reviewed” instead.

We encourage all add-on authors to try out the new Developer Tools and give us feedback.

Developer Tools is the area of the site that deals with submission and management of hosted add-ons, and is among the most complicated parts of AMO. Our rewrite brings these tools into our new codebase, which should result in faster performance and better cache invalidation, a common annoyance over the years.

The new tools also sport a brand new interface that aims to make common tasks very easy. For example, it’s now possible to update your add-on’s compatibility without ever leaving the dashboard view.

Also launching as part of this rewrite will be the new add-on review system discussed in mid-2010. Developers of add-ons currently in the sandbox will be affected by this, and will receive an email shortly after launch with instructions on what to do to stay on AMO.

One feature of the new Developer Tools that will likely be noticed by more than just developers is the introduction of add-on slugs. Add-on URLs will now have slugs, such as “adblock-plus” instead of an ID, though IDs will still work.

We invite any developers to help us test these new tools on our staging server and report bugs and give us feedback. Any modifications made to your add-ons on the staging server will not affect your real add-ons in production. Try the new tools.

How can you keep track of releases? One way is to download the latest beta and check for updates regularly. New versions are normally being released every few weeks. You can also visit the Releases page regularly. Finally, you can follow the Mozilla blog and keep up with Firefox news.

In this blog post I’m going to cover all breaking changes introduced in Firefox 4 that I’m aware of, including the ones I mentioned on my previous 2 posts (Part 1, Part 2). Firefox 4 is the largest release so far in terms of code and API changes, so there’s likely something on this list that affects your add-ons. This list is as thorough as I could manage to make; my objective is to make it as easy as possible for you to update your add-on so your users won’t have a hard time deciding if they should update their Firefox or not.

Add-on Packaging and Development Environment

In order to improve Firefox performance, a lot of work is being done to improve file loading and processing at startup. This includes add-on files as well, so there are a couple of changes that concern us.

Packed extensions

Firefox 4 will ship with most code files packaged in a single JAR file, also referred to as Omnijar. Reading files from a package is generally much more efficient than reading them independently from the filesystem, so keeping as many files as possible packaged together is a performance win, specially on mobile platforms. The same idea is now extended to add-ons, and by default they will be installed in the profile folder without unpacking them. There are some consequences to this:

1. Some add-ons will not work without unpacking, notably add-ons with binary components or other libraries. This also affects dictionaries and add-ons that include search plugins or window icons. Those add-ons that need to be unpacked must add an unpack flag to their install.rdf manifest.
2. If you read any files that are contained in your XPI from the profile dir, this won’t work anymore. You can extract them using the chrome protocol or the nsIZipReader component, or find other ways to generate them. You can also use the unpack flag if nothing else works.
3. You can still have you working directory in your profile as you did before. The extension loader will check for either the XPI package or the unpacked directory. However, for the final build you should aim to have your add-on installed without unpacking.
4. It’s also recommended that you move away from the previously recommended practice of packaging all chrome files in a JAR. Since the XPI is not unpacked anymore, having the JAR (a package within a package) only adds overhead.

Caching

Firefox is now caching code and other resources more aggressively. To make sure that your development profile is always picking up the changes, you should run Firefox 4 with the -purgecaches command line option. This will clear all relevant caches, to make sure you’re running the latest code.

The Profile Manager

The Profile Manager tool we’ve grown accustomed to is being taken out of Firefox. There’s a long discussion surrounding the reasoning behind this decision. In a nutshell, the profile manager hasn’t been updated for a very long time and is lacking in features, on top of some of its code causing slowdowns at startup. Needless to say, it won’t be removed without a suitable replacement. Bug 539524 is tracking this new development. The new tool will work independently from Firefox, kind of like a launcher script, and is meant to be more robust than its predecessor. Since this tool is not bound to the Firefox 4 release timeline, it could be finished after Firefox 4. You can always use the Firefox 3.6 Profile Manager in the meantime, of course.

Global extension installation

The -install-global-extension and -install-global-theme command line options have been removed. Global installation has always been a tricky subject, but there will surely be discussions in the future on how to move this forward while respecting users. For alternatives on how to automatically install add-ons, read this documentation at MDC.

XPCOM

XPCOM Registration

Components now need to be explicitly declared in the chrome.manifest file. This includes binary components as well. A number of startup observer topics have been removed, leaving only one: profile-after-change. Listeners and category registrations also need to be declared in the manifest and, because of this, some category names have changed. More details at MDC: XPCOM Changes in Gecko 2.0.

More

xpcnativewrappers=no is going away. This practice has always been considered unsafe, and there are safer alternatives for it.

The new Gecko SDK is still not available at the MDC page. Developers that use binary XPCOM have to build it themselves from source. The source code for beta releases is available at the FTP site.

The old and deprecated nsIPref interface has been removed. This shouldn’t affect anybody using the recommended nsIPrefService or the FUEL library.

UI

Toolbars

Toolbar buttons have different dimensions. Here are the current icon sets for the major platforms:

• Windows. Icons are 18 x 18 px. They have a very simple style and appear to be same for Aero and non-Aero.
• Mac OS X. Icons are 20 x 20 px. Simple style as usual, but this time around the icons don’t include the surrounding button style, making them more consistent with other platforms.
• Linux. Icons are 24 x 24 px. As usual, the theme relies mostly on Gnome icons.

This is a radical departure from the 3.6 icons. Only Linux retains the same icons and icon sizes, so you’ll need to create new toolbar icons for Firefox 4 unless you want to deal with scaling (you don’t). Fortunately, the chrome manifest file allows you use some convenient flags that allow you to easily separate skins depending on OS and application versions.

Also, if your add-on creates a new toolbar with an overlay, you may find that your toolbar is not showing up. This happens when your toolbox element overlay is a child of the window element, instead of a direct child of the overlay element. Moving the node out fixes the problem.

The Firefox App Menu

The main menu (File, Edit, View, etc.) is now hidden by default for Firefox 4 on Windows. Instead, there’s a single button that opens a simplified Firefox App Menu. This menu includes the most used menu features, making users’ lives easier. The “classic” menu can still be toggled using the Alt key.

If your add-on is only discoverable through the main menu, you’ll want to overlay the app menu as well. There’s no exclusive spot for extension menu items, so you should study the menu and identify the best one for yours, and then find the right ids for your overlay.

The Statusbar

It’s gone. It has been replaced with the Add-on Bar.

By default, there will be no more chrome at the bottom of the browser window. If an add-on adds an icon or something else to the Add-on Bar, it will appear in the same location and with a similar style as the current statusbar. The Add-on Bar has the advantage that it is a proper toolbar, and it may allow user customization in the future (but not in Firefox 4?). It has the disadvantage of being turned off by default, and also being thicker, meaning that users will not be very welcoming of add-ons that add stuff down there.

For backward compatibility, the old statusbar is now completely contained in the Add-on Bar. So, if your add-on overlays the statusbar, it will continue to work. This is only a transitory solution, so you should look into moving your buttons out of the statusbar and into the Add-on Bar as soon as possible.

Tabs

Beta 4 shipped with a new feature called Firefox Panorama (formerly known as Tab Candy). This is a major new feature and a new way to look at and manage tabs in Firefox. Unfortunately this also means that some tab manager add-ons may break due to the changes introduced in the Firefox tab code. There’s a new button in the tab bar that triggers Panorama, and also a tab context menu option.

Tabs appear on top by default. There is a preference that controls the location of the tab strip and toolbars.

App tabs. It is now possible to toggle tabs into app tabs, which basically means they can’t be easily closed and their titles are hidden, only showing the favicon.

The Add-on Manager

Firefox 4 has an overhauled Add-on Manager, no longer opening as a separate window but as a new tab. There’s much more room for add-on information, and the space for your add-on icon is now 64 x 64 px. The old 32 x 32 px icons still look OK (they are not scaled), but you’ll probably want to upgrade. Scaling down to 32 x 32 is not too bad, so you can include the larger icon without having to worry too much about backward compatibility.

The Add-on Manager backend was also overhauled. The nsIExtensionManager interface is no more, along with its RDF storage. Add-on metadata is now stored in a SQLite database, and the Add-on Manager is now a JS Module named AddonManager. A key difference in this new interface is that requesting add-on metadata is 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 anyway.

XUL and Overlays

The DOM surrounding the tabs and their internal browser elements has changed to allow easier overlaying. However, this means that if your code browses the DOM using parentNode, like to get access to the associated notificationbox of a tab, you may find that this code no longer works. This is something you shouldn’t be doing anyway, since the gBrowser object and its related objects have convenient methods to access these nodes.

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

Remote XUL is a rarely used feature in Gecko browsers that allow developers to create websites using XUL and XBL instead of (or along with) HTML. Since XUL support is limited to a few browsers, it never made much sense to create websites with it. However, it has been used successfully on a number of internal business applications (also known as “XUL dark matter”), and even some public websites.

Remote XUL has been a big maintenance problem, and 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 on webpages anymore. This also means that inserting XUL into (remote) HTML pages will not be possible anymore, not even for add-ons in some cases. If the code is loaded from a chrome URL, like in an iframe or an XBL binding, this should continue to work.

In a nutshell, XUL content from remote sites of even the local file:// protocol won’t load. Not all is lost, however. To enable a transition period from XUL to something else, remote XUL support hasn’t been entirely removed, only disabled. There’s a whitelist where individual domains can be added in order to enable XUL and XBL on them. This whitelist is not accessible from the UI, though, so I’ve created the Remote XUL Manager add-on to fill this gap. You should be able to easily manage the whitelist with this add-on.

Other

• JS objects can no longer be passed between threads, making the Thread Manager object fairly useless for add-on developers. This is a last minute fix that will hopefully affect just a few developers, but it will have a high impact because there are few alternatives available at the moment. There are discussions about improving the ChromeWorker interface so that it becomes a suitable replacement, but it remains to be seen if this will happen in the coming betas.
• User Agent strings have been minimized for privacy reasons. In order to align with these efforts, AMO Editors will 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 remove this code.
• There’s one bug that affects theme developers on Windows, and causes a black box to appear near the titlebar. There are a few workarounds explained in this Mozillazine thread.
• JSON Strings with trailing commas are no longer accepted by the SpiderMonkey JSON parser.
• The network redirects API has changed to be asynchronous now. This affects any extension registering in the “net-channel-event-sinks” category, breaking all redirects.
• 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.
• Firefox 4 will support the 32 and 64-bit Intel architectures on Mac, and has dropped PPC support. List of supported platforms.

Documentation and Help

We’re trying to publish as much documentation about Firefox 4 as possible in order to help add-on developers get everything right the first time. The Firefox 4 for Developers article is the official source for everything that’s new in Firefox 4, including breaking API changes. There are, however, many things included in this post that are not included in the article. I tried to cover everything I’m aware of, and if anything else changes or is discovered during the release process, it will be documented in this blog.

If there’s anything you think I’ve overlooked, or you want to discuss about Firefox 4 compatibility, this thread in the Add-ons Forum is the best place to go. You can also join our #extdev IRC channel for one-on-one live help. I usually hang out on that channel, but there are also lots of other experienced developers willing to help. Just join the channel and ask your question.

Finally, if you have a featured add-on, or you want your add-on to qualify to be featured on AMO, you should take into consideration that after Firefox 4 RC1 is released, add-ons must be compatible with the latest release in order to qualify. RC1 is scheduled for January 2011, so make your plans accordingly.

Happy coding!

• 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.
• 48 new nominations that week. 60 nominations in the queue awaiting review.
• 62 updates that week. 49 updates in the queue awaiting review.
• 323 reviews performed by AMO Editors this month. There were 12 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 5 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.

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:

• Beta 6 is coming, and it will be the first beta after feature freeze. This means that no major features will be added to Firefox after this release, and all releases following it will be dedicated to fixing bugs, regressions, optimizations and cleanup. I will be messaging all developers that have 3.6-compatible versions and haven’t been following the betas.
• As of Beta 5, Firefox has a new User Agent String.
• Firefox 4 will support the 32 and 64-bit Intel architectures on Mac, and has dropped PPC support. List of supported platforms.
• As mentioned before, Remote XUL over HTTP and over the file:// protocol has been disabled by default. There’s a simple API that allows you to whitelist individual domains in case you still need it.
• The channel redirection API has been changed to be asynchronous. This can break add-ons that deal with low-level networking functions.
• 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.

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

A video tour of the new features

Mark your favorites and get back to them quickly

Most people use collections to keep track of their favorite add-ons, so we’ve made it one click to favorite an add-on from almost anywhere on the site. You’ll automatically have a private My Favorite Add-ons collection where all of your favorites will be stored.

Instantly add to your existing collections or create new ones

Placing an add-on in any other collection is as easy as favoriting: just click the Add to Collection icon and select its destination. If you want to start a new collection for it, you can do that from anywhere now too!

Easily follow, share, and manage collections

Similarly to add-on listings, it’s now possible to follow, share, and edit collections from anywhere you see them listed in the Collections Directory. We’ve also made the directory navigation easier to understand.

Better collection permissions and URLs

With more than 64,000 collections created in the last 14 months, it can be difficult to find a unique URL for a new collection that isn’t already in use. We’ve changed the URL structure so that all of your collections are under your username and can be called anything you want. Existing owners of collections may want to read our Migration FAQ.

We hope you enjoy these new features and are working hard on many other improvements over the coming months. If you haven’t explored collections yet, now’s a great time.

Visit the Collections Directory

• 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