Mozilla Add-ons Blog

With the Firefox 3.5b4 release, we’ve enabled the 3.5.* maxver in the AMO Developer tools. For the vast majority of add-ons without binary components, you can simply update your maxver to 3.5.* and it will be compatible with all versions of Firefox 3.5 through the release. If you do have a binary component, you should only have to recompile your code against the latest- for more info see the Firefox wiki.

Thanks!

Last Friday, it was announced that Firefox 3.1 will be renamed to Firefox 3.5. What does this mean for add-on compatibility?

Right now, Firefox 3.1b4pre is available as a maxVersion on AMO, and can be used by any add-ons that support current Shiretoko builds. On Tuesday, March 17, these builds will be renamed to 3.5b4pre, and the maxVersion on AMO will be renamed accordingly. This means that as an add-on developer, if you mark your add-on as compatible with 3.1b4pre before Tuesday, it will automatically change to support 3.5b4pre when necessary. After Tuesday, developers can simply start using 3.5b4pre as their maxVersion.

Similarly, Firefox 3.2a1pre will be renamed to 3.6a1pre on Tuesday. Any add-ons currently compatible with 3.2a1pre will automatically be 3.6a1pre compatible on Tuesday.

Followers of the add-on compatibility dashboard may notice that it will no longer be accurate after the renames on Tuesday. The AMO team is planning to support version grouping of Firefox 3.1 and 3.5 with its 5.0.4 release to be deployed on April 9.

Additional compatibility updates will be posted here on the Mozilla Add-ons Blog.

This post is here to warn a subset of add-on authors that we’re making some late changes to the IID for some interfaces on the Gecko 1.9.1 branch.  A very small subset of people are likely affected based on our scan of a bunch of add-ons.  Note that this doesn’t affect the methods on the interfaces themselves, just the IIDs for interfaces.  So it should not require a functional change.

What we’re changing:

Based on a report on the dev-platform mailing list there are some interfaces that were changed between Gecko 1.8.0 and Gecko 1.9.0 without changing the IID for that interface.  Gecko 1.9.1, which inherited the code from Gecko 1.9.0, currently contains this error as well.  [Note that most of the discussion of the reported issue appears to be missing from Google Groups.  We are not sure why this is, but we assure you there was a long discussion of the issues.]

There are apparently some extensions for Thunderbird which need to be able to detect which version of an interface is being used based on the IID.  (Thunderbird 2 and Firefox 2 were both based on Gecko 1.8.0 and Thunderbird 3 and Firefox 3.1 will be based on Gecko 1.9.1.)  In order to make detecting that difference possible we need to make the change in the 1.9.1 branch before we release Firefox 3.1, as that will also serve as the baseline for Thunderbird 3.

These are the affected interfaces listed in the post and have been changed ahead of the release of Firefox 3.1 Beta 3:

475897 imgIContainer
475898 jsdIDebuggerService
475900 nsIAbDirectoryQueryArguments
475901 nsIAccessibleValue
475912 nsITokenDialogs
475913 nsIXULWindow
475915 nsPIWindowWatcher

These interfaces will be changed by the mailnews team before the release of Thunderbird 3:

475909 nsIMailtoUrl
475903 nsIFolderListener
475904 nsIImapMailFolderSink
475906 nsIImportMail nsIImportMailboxDescriptor
475907 nsINNTPNewsgroupList

Am I affected?

Very few people are likely affected by this change.  You might be affected if:

1. Your extension includes binary components written in C++ and uses the affected interfaces.
2. Your extension is loading an affected component using the IID instead of by name.

JavaScript-only extensions that refer to components by name instead of by IID will not be affected by this change.  This is almost all extensions.

What do I have to do if I’m affected?

If you’ve got an affected C++ component all you will have to do is rebuild your component with the new header files and re-release it.  We’re not changing interfaces, just the IID associated with them.

If you’ve got a component in JavaScript and you’re using interfaces by IID instead of name you will have to change the IID in your extension and re-release.

As I’m sure you’ve noticed, we’re pretty hot on getting as many add-ons as possible up to Firefox 3.1 beta 2 compliance. For users, it’s extremely important that the add-ons that make their browser unique and useful are immediately available when a new version of Firefox is released.

The most cumbersome part of this whole process is having to do a new build of your add-on just to change the maxVerison in install.rdf so you can test it out. Well, that’s not necessarily the case and while more experienced developers may know this, I want to ensure that contributors that are new to the Mozilla platform are aware that you can test your add-on in Fx 3.1b2 without having to physically update it.

All builds of Firefox allow you to turn off the add-on compatibility check which prevents unsupported add-ons from running in newer versions of the browser. By disabling this check, you’ll be able to install your add-on and run it through its paces. The process is painless and described below:

1. In your address bar, type the following: about:config

2. You may see a message that says, “This might void your warranty!”. Click on the “I’ll be careful…” button

3. Right click on any entry to display the context menu and select New > Boolean

4. Set the preference name to extensions.checkCompatibility and the value to false

5. You should now see the new entry listed

6. Finally, restart Firefox and install your add-on

Once you’ve tested your add-on, you can then decide how to best handle the maxVersion update. In many cases, if your add-on works perfectly and does not require any Fx 3.1-specific code changes, you can simply update the maxVersion via the developer tools on AMO.

If you find that your add-on isn’t working correctly, then that’s when you’ll need to correct any issues and upload a new version for review. The following page lists common issues that may cause your add-on to break:

https://developer.mozilla.org/En/Updating_extensions_for_Firefox_3.1

As Nick mentioned earlier, as of Fx 3.1b2, no changes are planned which should affect add-on compatibility so now is a great time to ensure you’re compliant and that your users will be able to continue to take advantage of your excellent work.

NOTE: Please be sure to set extensions.checkCompatibility back to “true” once you’re done testing. Otherwise, you’ll bypass checks during your normal browsing that could dramatically affect your experience. It should ONLY be set for testing your add-on and is not recommended for normal browser usage.

3.1 is coming!  We know that many add-on developers have held off on testing for 3.1 compatibility because they’re waiting for a near-final release to test against.  I’m happy to report that as of 3.1b2, no changes are planned which should affect add-on compatibility.  For those of you who migrate to 3.1b2, chances are extremely high that no further compatibility changes will be required for subsequent beta releases up to and including the final release.

Don’t hesitate!  With each subsequent beta, more people make the switch and having 3.1 compatibility will ensure a seamless upgrade experience for your users.

In many cases, your add-ons will work on 3.1 without any changes, so if you test and find this to be the case, simply update your add-on compatibility to 3.1b2 and it will automatically be recognized by Firefox during the startup version check.  If you do find that you’ll need to make code changes, we will prioritize 3.1 compatible extensions in the review queue to make sure that they are approved in a timely manner.

Finally, compatibility will be a requirement for any additions to our Featured and Category Recommended lists- so if you want to be considered for these lists, please make sure your add-ons work on 3.1.

Here are some useful links:

Download Firefox 3.1 Beta 2

Updating Extensions for Firefox 3.1

Firefox 3.1 Beta2 is here ! As we said before, it’s time to update your add-ons. Many add-ons should work out of the box with beta2. Others might need a little tweak.

If you have tested and you are sure that your extension works with Firefox 3.1 beta 2 and doesn’t need any code update, just update the compatibilty version (3.1b2) on the AMO dashboard. This is enough.

If you know that you must update some code, do so and update the install.rdf file (increase the version of your extension and update maxVersion to 3.1b2), then upload your xpi file.

If you feel unsure about how to update your add-on, here are step by step instructions on how to update it. The following may sound very easy. That’s probably because it is easy.

1. First, download Firefox 3.1 beta 2 here:

http://www.mozilla.com/en-US/firefox/all-beta.html

2. Next, test your add-on:

Edit your install.rdf: if needed, update maxVersion to 3.1b2, and increase the version of your add-on.

Create a new Firefox profile:
firefox --createProfile testBeta2
Launch firefox with the new profile:
firefox -P testBeta2

Install your add-on.

Test your add-on thoroughly. Ensure that there’s no weird behavior or javascript errors.
We encourage you to set these preferences:
user_pref("javascript.options.strict", true);
user_pref("javascript.options.showInConsole", true);
in order to be notified about any javascript exception or warning.

If you run into issues, please check these common issues that may cause your add-on to break:
https://developer.mozilla.org/En/Updating_extensions_for_Firefox_3.1
Even if you think you won’t run into any problems, we still strongly recommend you read this page. You never know.

Then, make sure that your add-on works on your current profile (with all data already set by the last version).

3. Update your add-on on AMO:

If your add-on does not need any code update, just update the compatibilty version on the AMO dashboard.
if your add-on does need code update, then upload the new version to AMO.

That’s all!

Update your add-ons. It should be easy. If you run into issues during the migration or if you need some support, see our last post.

Hello,

In order to help add-on authors migrate to Firefox 3.1, the Mozilla evangelism team is working on documenting changes between Firefox 3.0 and Firefox 3.1 which could affect extensions.

Some of you have already updated your extensions to Firefox 3.1 beta, or are in the process of doing so, and we’re asking for your help by providing some useful feedback about the migration.

We are interested in any issues you’ve encountered including interface changes, unanticipated behaviour or any API updates. You can provide feedback as a comment to this post and any information will help, even something as simple as:

“I ran into problems with interface XYZ”

Your assistance will be invaluable in helping us identify migration issues and ensuring that Firefox 3.1 has high rate of add-on compatibility upon release.

Thanks a lot.

Justin Scott has worked hard on creating a compatibility dashboard to help us understand how the add-ons universe is preparing for new versions of Firefox.

The live version is up on addons.mozilla.org. Check it out!

Cross-posted from Justin Scott’s blog.

I recently posted about the start of the campaign to get add-ons ready for the upcoming release of Firefox 3.1, and wanted to explain what our goals are and how we’ll be tracking progress.

As with previous Firefox releases, we’re aiming to have 90% of add-ons that make up the top 95% of add-on usage compatible with Firefox 3.1. That’s not an easy goal to comprehend, so I’ll explain what it means and why we do it.

Every day, the Mozilla Add-ons website gets around 135 million update checks from add-ons installed in Firefox and Thunderbird applications all over the world to determine if any updates are available. While there are some extensions that account for several million of those pings alone, there are many extensions that are not as popular and may have less than 100 active daily users. To make sure our outreach efforts benefit the most end users, we rank the add-ons by their number of active daily users and focus on helping the add-ons that make up 95% of the total add-on usage.

As shown in the above graph, only 861 add-ons as of last Wednesday make up 95% of the total update pings, while 5% is accounted for by the much larger number of 4943 add-ons. Our goal is to get 90% of these 861 add-ons compatible with Firefox 3.1.

For the Firefox 3 effort (Operation Threedom), Alex Polvi created a status bar page that helped visualize our current progress. For 3.1, we’re taking it a step further and integrating a Compatibility Center within AMO that can always be checked for the latest progress.

The new tool isn’t available yet, but should be within a week or so. Here’s a screenshot of our current progress:

As shown, we currently have 20% compatibility. The report is customizable by version, so the current Firefox 3 version of the chart shows 94% compatibility. More screenshots and progress can be found in bug 460309.

We’ll be posting periodic updates on the progress of the Firefox 3.1 compatibility push to the new Add-ons Blog and in various other add-on communication channels.