This post lists the first batch of these features that will be removed in the coming months.

Ending Self-hosted Pilot Program

In November of last year we announced a pilot program allowing developers to create listings on addons.mozilla.org for their add-ons without requiring the add-ons to be hosted or reviewed by us. We hoped this would create a more comprehensive directory of add-ons where users could find any Firefox add-on they were looking for, even if it wasn’t hosted by us.

It’s been almost a year, and after reviewing the results of the program, we have decided to end it. We haven’t seen the kind of adoption we were looking for and still find that many of the best add-ons that aren’t hosted on AMO did not participate. Instead, add-ons that were already listed on AMO switched to self-hosted to avoid complying with certain review policies.

Self-hosted add-ons are difficult to maintain in our code base, as they require exceptions to almost everything we implement. We’re starting work on our new Developer Tools area of the site and could not justify re-implementing them in our new framework given their usage and maintenance cost. Finally, as announced earlier this year, we’ll soon be moving to a review model where every add-on available in our gallery must be reviewed for security. As self-hosted add-ons are not reviewed or hosted by us, they don’t quite fit in with our new standards.

Migration

Support for self-hosted add-ons will end with the launch of our revamped Developer Tools, likely in November. Developers of affected add-ons will receive an email prior to this time. We recommend converting your self-hosted add-on into a fully hosted add-on at least 2 weeks before that time period to allow for editor review and post-review modification. Once support is removed, all remaining self-hosted add-ons will be disabled.

Email Sharing

We implemented the ability to share add-ons and collections via email last year, but haven’t seen it used much at all. Requiring users to log in is likely a huge barrier to this feature’s usage, but for now we’ll be removing the feature until that and other issues can be resolved at a later time.

User Tagging

Currently, any registered user can tag an add-on to help classify and group similar add-ons. We’re going to simplify this by only allowing developers to tag their add-ons. Add-ons will have a maximum of 20 tags, and the migration to the new format will prioritize the developer’s tags and fill remaining slots with user tags. Once this process is finished, developers can delete any migrated tags they don’t wish to keep.

First, the key documentation:

• Firefox 4 for Developers. This is the definitive document, but it can be a little out of date given that documentation is normally added only after bugs are finalized and somebody from the documentation team picks it up.
• Add-on compatibility for Firefox 4 – time to get started. The first installment in this series of posts. It contains most relevant information up to Beta 1. I’ll try to repeat myself as little as possible in this second part.
• Firefox 4 Compatibility discussion. If you have questions or input regarding Firefox 4 compatibility, this is the best place to discuss it. You can also comment on this blog post, but that’s less visible for other developers.

And now, the new stuff.

New UI Features

Beta 4 shipped with a new feature called Firefox Panorama (previously 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. I’ve been told that the changes to the tab code are minimal, but I know that at least Tree Style Tab (a personal favorite) is broken since beta 4. There’s a new button in the tab bar that triggers Panorama, and also a context menu option.

Details about the Firefox 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. That doesn’t sound right at all, so it’s possible it will change in the future.

Toolbar buttons are being handled very differently and have different dimensions. Since this essentially breaks most add-ons, there’s some ongoing discussion about it. The new designs require you to create only the inner part of the button, and let CSS generate the border, background and padding around it. You can use CSS to override this behavior, as usual. These are the current icon sets for the 3 major platforms: Windows, Mac and Linux. They should give you a good idea of the new icon dimensions and states. The icons for Linux are pretty much the same as before, as it seems that Firefox is (for the moment, at least) still relying on standard Gnome icons to populate the toolbar.

Development and Packaging

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.

If you edit your add-on files directly in your development profile folder in order to test changes quickly, you may find yourself wondering why the changes aren’t being picked up by Firefox 4 the same way as before. What’s happening is that Firefox 4 is now caching certain code files more aggressively now, and a couple of bugs were introduced in this code. Bug 531886 and bug 520309 are the key bugs here. The proposed solution is that there will be a command-line option to disable the cache and allow developers to continue working this way, but that still won’t work for all file types until bug 531886 is fixed.

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 that reading them independently from the filesystem, so keeping as many files as possible packaged together is a performance win, specially on mobile. The same idea is being extended to add-ons, and the work being done in bug 533038 will add a new feature that add-ons can opt-in to in order to load more efficiently. The idea is that you will be able to include a new tag in install.rdf that indicates that your add-on can be installed without extracting the files from the XPI. This will depend on the file types that can be read from the package, so for the moment it’s unlikely that add-ons with binary components will be able to opt-in, and themes may have some limitations due to their preview images. It’s also recommended that you move away from the usually recommended practice of packaging all chrome files in a JAR. None of this is part of Firefox 4 yet, so it’s still malleable, but it will appear in upcoming betas.

Also coming in future releases, a new profile manager. Bug 539524 is tracking this new development, and it seems that the new tool will work independently from Firefox, will have more interesting features, but will also lack the UI we’ve grown accustomed to. 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 unless there’s a suitable replacement.

XPCOM

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. Thanks to Matthew Wilson for the catch.

If your XPCOM component reads input data from the command line, this registration will now need to happen through chrome.manifest. However, the documentation still doesn’t specify how to do this. Thanks to Jason Barnabe for the notice.

More!

There’s surely more coming up, and if I’ve missed something, please let me know. There will be a least on more post in this series, after the trunk goes through “feature freeze” and Firefox 4 begins to feel like the real deal.

Remember: if your add-on is already compatible with the latest beta but your install.rdf file isn’t up to date, you can go to the Files and Versions section of your add-on in the Developer Hub and update the compatibility info. No need to upload a new file!

Happy coding!

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.

The policy page won’t be updated until the next AMO release, sometime in mid April, but most of these policies are already in place, and the AMO Editor team is making sure they are followed.

Adding advertisements to web pages is strictly forbidden

Content producers often place ads on their sites in order to make money, and that’s OK. Ads can be annoying and intrusive, sometimes making the reading experience awkward or even impossible. So there are add-ons designed to filter out advertisements, and we think that’s OK as well.

What’s not OK in our minds is for add-ons to take advantage of web content and embed their own advertisements on it. To be able to filter ads in order to provide greater user control is one thing. To replace or extend advertisements for financial gain, at the expense of user control, is something else entirely.

We’ve never had to think about this before, but it was brought to our attention that a framework called FatPlug was designed for this specific purpose, and many add-on authors had been approached in order to include it in their add-ons.

To be perfectly clear: no add-ons using FatPlug will be allowed on AMO, not even in the sandbox. We’ll be adding a flag in our code validator very soon.

Generalization of No Surprises

Our No Surpises policy succinctly explains that we demand nothing less than complete transparency from add-ons:

Surprises can be appropriate in many situations, but they are not welcome when user security, privacy, and control are at stake. It is extremely important to be as transparent as possible when submitting an add-on for hosting on this site. A Mozilla user should be able to easily discern what the functionality of your add-on is and not be presented with unexpected user experiences post-install.

However, the text following it is a little too specific, referring to homepage and search engine defaults. The spirit of No Surprises is not limited to those, and we’ll be updating it to make sure it’s clear what we mean. We haven’t decided on the exact wording, but I’ll try to put it the best way I can: whenever your add-on includes unexpected features that are unrelated to its main function and could compromise user privacy or security, the feature must be opt-in, and all privacy concerns must be spelled out in the Privacy Policy.

The policy document will be updated soon.

Conduit toolbar add-ons allowed, with restrictions

Conduit toolbars used to be forbidden on AMO, partly because of the sheer amount of add-ons being submitted, and more importantly because of problems with their quality and privacy standards. All of these issues have been worked out with Conduit and we have been in constant communication with them in order to make Conduit toolbars acceptable again on AMO.

A couple of months ago we finally reached the point where we all think it’s OK to allow Conduit add-ons. However, in order to make sure they are all held to the same standards, only Conduit-approved add-ons will be accepted for review. If you’re interested in listing your Conduit add-on on AMO, please contact Conduit about it.

Like I said, this isn’t a recent decision, but I was reminded of a promise made about announcing it.

Private Browsing Mode Support

PBM support will become a requirement beginning April. Make sure you read and understand that post. This will be included in our policy page very soon.

codebase_principal_support and enablePrivilege no longer allowed

Support for the signed.applets.codebase_principal_support preference and the enablePrivilege function will be dropped soon. Add-on authors that rely on this feature will need to find alternatives for it immediately, and editors are already rejecting add-ons that use it.

I wouldn’t count this as policy, but I thought it’d be good to include.

In July, we asked developers to take a survey about how they use the Statistics Dashboard, and as part of our AMO rewrite currently underway, we’ll be revamping the dashboard.

Here’s a mockup from our designer, Chris Howse, of the overview page of the new dashboard:

A few comments on the new design:

• Our main goal was to simplify the dashboard and present the most common things developers are looking for up front, answering questions like “which application versions is my add-on used with?” and “how many people use my add-on on Mac?”
• Each of the breakdown pages will have its own URL and be linked to directly, eliminating the annoying dropdown menu currently used
• We’ll be replacing the Timeplot graphs with nicer, less buggy graphs using Highcharts
• Most of the features of the new dashboard exist in the current dashboard, but this will create a much better platform and layout for us to add additional features after the rewrite. We already have some great ideas to implement at that time.

You can see the rest of the mockups and design discussion in bug 540885 and implementation in bug 543548.

With tonight’s release, we’ve launched a pilot program to allow self-hosted add-ons to be listed on AMO alongside our thousands of Mozilla-hosted add-ons. We want users to be able to find any add-on they’re looking for on AMO, whether it’s hosted there or not.

These self-hosted add-ons won’t have all of the site features that other add-ons do, but will appear in search and browse listings, collections, and can be reviewed and rated. However, unlike our thousands of publicly-listed add-ons, these add-ons are not reviewed by Mozilla. Because of this very important distinction, instead of a green install button, self-hosted add-ons see a cautionary notice and link to the add-on’s homepage for additional information and to install the add-on.

Developers interested in submitting their self-hosted add-on or changing the hosting of their existing add-on should first read through additional details of the program.

Additionally with tonight’s release, we’ve added support for a much-requested feature over the last few years: HTML in add-on descriptions!

Several HTML tags, including links and lists, can now be used in four fields across the site: add-on descriptions, developer comments, version release notes, and user profiles. These fields and several others will also automatically link plain text URLs.

Stay tuned for information on additional features included with this release tomorrow!

Developer Hub

Back in May, we posted about our plans for a developer-focused website in response to feedback we received from add-on developers. The new Developer Hub has something for everyone — whether you’re just getting started or have already made twenty add-ons.

New documentation features of the Hub include:

• Getting Started – an introduction to add-on development with links to important resources
• How-to Library – tutorials, articles, videos, and walk-throughs on add-on development topics
• API & Language Reference – official API and language references
• Case Studies – stories of successful Firefox add-ons
• Add-on Policies – all of our add-on policies in one up-to-date location
• Search – search the best add-on development resources in one place: documentation, forums, newsgroups, reputable blog posts, and more

We’ve also introduced some new tools, with more planned for the coming months:

• Add-on Builder – auto-generate add-on packaging by entering basic information and picking UI parts
• Add-on Validator – add-ons can now be validated even if they’re not hosted on AMO

One of the most important goals of the new Hub is to bring the add-ons community closer together. With that in mind, the Hub features:

• Add-ons Forum – interact with other add-on developers and get help
• Newsletter – about:addons is our monthly newsletter
• Developer News & Promos – relevant news and important information is now prominent throughout the Hub
• Upcoming Events – find out when an add-on event is coming to your area

Developer Tools & News Feed

The tools developers use to submit and manage their add-ons on addons.mozilla.org are now part of the Developer Hub, and we’ve added a cool new way to stay up to date with what’s happening with your add-ons: the add-on news feed.

Any time something of note happens to an add-on, it is recorded in the news feed for the developer to see. This includes developer and editor actions like editing an add-on, submitting a new version, and approving a new version, but also includes user actions such as reviews and collections.

The news feed is available via RSS for one or all of your add-ons.

Search Revamp

As part of this release, we’ve also re-worked our AMO search engine from scratch to provide much more accurate results. This is a huge and much anticipated improvement, and will be covered in detail in a separate blog post.

A big thanks goes to everyone who made this release possible, from the developers, testers, and designers to those who helped review documentation and content.

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.

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.

Today, we’re excited to introduce a new feature to our website that will expose the niche add-ons that can be hard to find, and gives users a more active role in helping outstanding add-ons bubble to the top. One thing we’ve learned as add-ons have grown in popularity over the years is that once a user finds an add-on they love, they become a fan for life. We see this all the time as people recommend add-ons to their friends and write great reviews. And we’re very happy to see so many bloggers writing about lists of their favorite add-ons.

We’ve created a short video demonstration to introduce this new feature:

Add-on Collections

In November, we launched Fashion Your Firefox, which was a collection of add-ons that we felt were great for a novice user just getting started with customizing their browser. Now, we’d like to take it a step further and let anyone create their own collection of add-ons that can be shared with their friends, posted on blogs, and featured on the Firefox Add-ons website.

Starting today, visitors to the add-ons website will see a brand new look with collections of add-ons front and center. We’ve integrated collections throughout the site, and created a Collection Directory that showcases all of the add-on lists created by our users. There are a number of Mozilla-created collections that are featured throughout the site, but we hope to replace these with useful community-created collections in the near future. If you find a collection you like, logged-in users can mark it as a favorite to easily get back to it later.

Creating a collection of your own is as easy as giving it a name, like “Ken’s Favorite Data Analysis Extensions” or “Halloween Themes”, and choosing what add-ons you’d like in the collection. It will then show up in the directory, and can be sent to your friends or linked in your blog. The more people add it as a favorite, the higher it will be ranked.

Staying up-to-date

There are a lot of add-ons out there, so finding a collection related to a topic you’re interested in will be a huge time-saver. But what if you want to subscribe to that collection so that you find out when new add-ons are published to it? You can subscribe to a collection via RSS, or you can install the Add-on Collector extension for Firefox. The Collector turns your favorite collections into subscriptions in your browser, where you’ll be notified as soon as new add-ons are published to one of your collections. The extension has a number of other features, including the ability to share an add-on you have installed with a friend by e-mail, publish an add-on to one of your collections, and set up a collection that is automatically kept up to date with your installed add-ons.

We’ve made video demos of creating a collection and setting up an auto-publisher collection to show how easy it is dive in to collections.

We hope that collections will make add-ons more social and encourage add-on users to be involved in the community. So, head on over to the Collection Directory to get started with collections and fashion Firefox the way you want it.

Note: There are currently some issues with logging in via the Add-on Collector extension. We hope to have these fixed Wednesday morning. Update: The Collector is now fixed and login should be working properly in version 1.0.2 of the extension.