SeaMonkey 2.0 has been out for a while, and it’s time for add-on developers to give it some love. If your add-on already works on earlier versions of SeaMonkey, you should update your add-on’s compatibility as soon as you can. If not, this is a good time to consider adding SeaMonkey compatibility and increasing your usage numbers .

SeaMonkey 2 is a big improvement from previous releases in terms of add-on support, and Firefox extension developers will find that it’s easy, sometimes trivial, to add support for SeaMonkey in their extensions. It only took me a couple of hours to add SeaMonkey support to my own add-on (a new version in development at the moment), and this is a fairly complex extension I’m referring to. Well, that plus a few hours making an important contribution to make it possible to port it .

If you’re curious about SeaMonkey extension support, this article at MDC is the place to go to: https://developer.mozilla.org/en/Extensions_support_in_SeaMonkey_2

Happy coding!

ShareThis

Attention Firefox mobile add-on developers: Please ensure your mobile add-on minimum and maximum version is compatible with both the Maemo AND Windows Mobile platform. We will be releasing our fourth alpha of Fennec for Windows Mobile very soon and we want to make sure users can discover and install your add-on directly from their device.

If you update your add-on’s maxVer in the Developer Control Panel to “1.1a1″, they will work with the latest version of Firefox for Windows Mobile.

ShareThis

If you are an extension developer and include executable files in your XPI package (binary or shell scripts) then you may be seeing problems in Firefox 3.6.

Back between Firefox 3.6 beta and Firefox 3.6 RC we took a small fix to the extension manager that changed how we extract the files from the XPI package. The fix involved adjusting how we accessed files to avoid hitting problems with certain anti-virus tools that would occasionally lock files in the middle of extraction making us fail to install the add-on. A side effect to this fix leaves us setting file permissions on the extracted files in a slightly different way to previously. This side effect means that the executable permission is getting stripped from all extracted files. If you try to execute these files with nsIProcess it will likely fail.

There is a bug on file and I have a patch almost complete so hopefully this should be fixed in Firefox 3.6.1 but until then you can workaround this in your extension by setting the executable permissions on the file yourself. Assuming you have a file variable that is an nsIFile pointed at the executable, just do:

file.permissions = 0755;

In case you were wondering why we enforce file permissions at all, it is because it turns out there are quite a lot of different zip tools that developers use to build add-ons. Some of them are unfortunately broken and embed bogus permissions into the generated XPI. After extraction it leaves us with files that are unreadable/unwritable which makes the add-on fail to work correctly. This most commonly affects developers on windows (where permissions are a little laxer in general) who get odd bug reports from users on Linux which is respectfully refusing to use the files. The easy fix is to enforce read/write permissions on the extracted file in the first place.

ShareThis

We just dispatched emails to the developers of those add-ons as follows:

• 105 add-ons that we think are compatible. These add-ons had more than 80% of reports saying the add-on worked fine. For these add-ons, we suggest that the developer test the add-on out themselves and then bump compatibility to Firefox 3.6.*.
• 24 add-ons with compatibility issues. These add-ons had more than 80% of reports saying that the add-on was not functioning properly. We ask the developers of these add-ons to review the submitted reports and look into the issues mentioned before bumping compatibility.
• 321 add-ons with mixed reports. These add-ons have received a number of reports, but we couldn’t make a guess as to the status. We encourage these developers to view the submitted reports and then test their add-ons before bumping compatibility.
• 830 add-ons with at least one report, but not enough to determine anything. We’ve asked these developers to test their add-ons with Firefox 3.6 and bump compatibility if everything checks out.

The response to the Compatibility Reporter has been amazing, with almost 20,000 active users helping us out. Your reports will make a big difference in being able to ship Firefox 3.6 without add-on compatibility issues, so keep it up!

ShareThis

As an experiment in ways to get users and developers involved with this process sooner, we’ve created the Add-on Compatibility Reporter, an add-on for Firefox and Thunderbird that allows testers to report compatibility information to Mozilla.

After installing the add-on, users will be able to use any incompatible add-ons they have installed and report back to us on whether the add-ons still work like they did in previous versions or are having some issues.

Add-on developers can then browse the reports submitted for their add-ons, even if the add-on isn’t hosted on Mozilla Add-ons. We’ll also be monitoring the report submissions and emailing developers when we have information as to whether their add-on might be compatible or incompatible with an upcoming Firefox release.

So, if you’re an alpha or beta tester of Firefox or Thunderbird and want to help make sure your add-ons are compatible for the final release, grab the Add-on Compatibility Reporter now!

ShareThis

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.

ShareThis

Thanks!

ShareThis

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.

ShareThis

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.

ShareThis

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.

ShareThis