Some of the important features included in this release are:

• Plural forms for localization – many languages treat plural forms of words in different manners. The SDK’s l10n functionality now supports those forms across languages.
• Implementation of ‘Promise Abstractions’ – Promises provide an interface for interacting with an object that represents the result of an action that is performed asynchronously, and may or may not be finished at any given point in time. In the Add-on SDK, we follow the CommonJS Promise/A Implementation.
• contentStyle/contentStyleFile – this give you the ability to inject a CSS file into a web page.

For more new features and a list of the bug fixes that are shipping in this release, please see the Release Notes.

As of this writing the documentation for SDK 1.7 is not available in the usual place, however they should be available by Thursday, May 17th. I will update this post when they are live, but in the meantime you have two options:

1. view them on Github: [ Tutorials & Guides ] [ Addon-kit API Docs ]
2. download the SDK, activate the SDK environment and then run cfx docs to generate your own local copy of the documentation.

As always, we’d love to hear from you about your experiences with this release. You can contact us in a variety of ways:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

For more information on the Jetpack Project check out our wiki.

You can grab the updated version of the SDK as a zip file or tarball and replace your older version. The release notes for 1.6 remain accurate with the exception of fixing bug 740689.

If you have any questions or issues with this hotfix release, please feel free to ask the jetpack team about it in any of the following areas:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

For more information on the Jetpack Project check out our wiki

The SDK documentation has been updated for easier navigation and more information, including tutorials on using a few community-built modules that aren’t in the core SDK. You can always find the latest documentation here: https://addons.mozilla.org/en-US/developers/docs/sdk/latest/

In addition to the documentation, this release has quite a few bug fixes. You can read more details of these fixes as well as some known issues in the release notes.

As always, we’d love to hear from you about your experiences with this release. You can contact us in a variety of ways:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

For more information on the Jetpack Project check out our wiki

The two most important new features of this release are:

• Mobile Support! – Developers can now start developing add-ons for the mobile version of Firefox. For the initial release of mobile compatibility we have the page-mod API working which will allow developers to create modifications to web content within their add-on. This is quite useful for creating mobile versions of website that do not have a good mobile support. This support for mobile Firefox is only for the new Native Android versions of Firefox (at time of this post, Aurora and Nightly). Primers on getting started developing add-ons for mobile Firefox can be found here and here.
• Localization! – Localization has finally come to the Add-on SDK! For this initial version localizers can translate javascript-embedded strings with HTML string support coming in a future SDK release. An introduction on how to localize strings can be found in the documentation.

For more new features and known issues in Add-on SDK 1.5, please see the Release Notes!

As always, we’d love to hear from you about your experiences with this release. You can contact us in a variety of ways:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

For more information on the Jetpack Project check out our wiki

If you are potentially affected by the bug, then you will need to take action to recover from it.

This note explains:

• how to work out whether you are potentially affected
• what the impact is
• how to recover from the bug
• what went wrong

Are You Affected?

You are potentially affected by this bug if you meet ALL THREE OF the following conditions:

1. Your add-on uses any of the following SDK modules: simple-storage, passwords, simple-prefs. Using passwords is only a problem if you’re using it to store passwords specific to your add-on, rather than just web site passwords).
2. You did not explicitly specify an ID for your add-onThis means: you didn’t edit your “package.json” file to set your add-on’s ID, so the first time you ran `cfx`, it generated an ID for you in “package.json”.If you’re not sure about this, open your add-on’s “package.json” file and examine its “id” entry. If it does not contain “@”, and is not in the form: “{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx}”, then it is an auto-generated ID and you meet this condition. For example:

       "id": "jid1-MKxcan0H26wiRw"

3. You have ever built and distributed your add-on using the 1.4, 1.4.1 or 1.4.2 releases of the SDK This means either:
   • you initially built your add-on with 1.4, 1.4.1 or 1.4.2
   • you initially built your add-on using 1.3 or an earlier release, but rebuilt it using 1.4, 1.4.1, or 1.4.2.

What’s the Impact?

The impact of this is:

1. suppose your add-on was originally built and distributed using a version of the SDK earlier than 1.4. People use it, and store data with it, using the simple-storage or passwords modules. Then you rebuild using SDK 1.4/1.4.1/1.4.2. Now, any data which users had previously stored in simple-storage, and any add-on-specific passwords stored using passwords, will seem to have disappeared. You must upgrade to 1.4.3 to recover this data.

2. suppose your add-on is built using SDK 1.4/1.4.1/1.4.2. People use it, and store data with it, using simple-storage, simple-prefs, or passwords. Then you upgrade to version 1.4.3. Now, this data will apparently disappear. You must take steps to recover this data.

How To Recover

First, upgrade your add-on to use 1.4.3. After this, data entered using releases of the SDK before 1.4 will reappear.

Next, you’ll have to recover any data that users entered using the 1.4/1.4.1/1.4.2 versions.

To help with this we’ve written a module called “recovery.js”. This module won’t ship with the SDK itself, though.

• If you’re using the Add-on SDK, download “recovery.js” from https://gist.github.com/1733262 and save it in your add-on’s “lib” directory.
• If you’re using the Add-on Builder, move your mouse over “Libraries” in the left-hand sidebar until a plus sign appears next to it, then click the plus sign. Then in the dialog type “recovery” and select “recovery by gozala” to add it to your project:

You need to import the recovery module in the normal way:

var recovery = require('recovery');

The recovery module contains any data that was written using simple-storage, simple-prefs, and passwords while your add-on was built with the 1.4, 1.4.1, or 1.4.2 releases of the SDK. The data is stored as three properties, one for each module:

• recovery.storage
• recovery.prefs
• recovery.passwords

You’ll need to merge these properties with the data stored in simple-storage, simple-prefs, and passwords in whichever way makes sense for your add-on.

The files at https://gist.github.com/1733262 include some examples of performing this merge using the recovery module.

What Went Wrong

SDK-based add-ons have an ID, which is used for, among other things, figuring out which stored data belongs to this add-on. The ID is stored in the add-on’s “package.json” file. If you do not specify an ID for your add-on by editing “package.json” directly, then the SDK generates one for you automatically.

This auto-generated ID in “package.json” looks something like “jid1-y1AFbAhD9jXVcg”. The SDK takes this value and appends “@jetpack” to it, and uses the result as an ID. So if you call:

console.log(require("self").id);

…you’ll see something like:

 info: jid1-y1AFbAhD9jXVcg@jetpack

This value is then used as a key for data stored using simple-storage, simple-prefs, and certain data in passwords (specifically, passwords that are associated with your add-on rather than a web site).

In 1.4 we broke the code that appends “@jetpack” to the ID. This means that a 1.4/1.4.1/1.4.2 add-on will look for data using just “jid1-y1AFbAhD9jXVcg”, and won’t find any data that was entered using an add-on built against an earlier version of the SDK.

In 1.4.3 we are reverting that change: so a 1.4.3 add-on will look for data using “jid1 y1AFbAhD9jXVcg@jetpack”. This means that a 1.4.3-based add-on it will find data which was entered using an add-on built using pre-1.4 release of the SDK. However, a 1.4.3 based add-on *will not* find data entered using an add-on built against 1.4/1.4.1/1.4.2. That’s why you have to recover that data explicitly.

We considered making the 1.4.3 release perform automatic recovery, looking for data stored under “my-jid”, and if it finds any, automatically updating the version stored under “my-jid@jetpack”. But the structure of stored data is very specific to an add-on, and we decided that there was a significant risk that automatic update would break some add-ons, so it’s safer if each add-in implements its own recovery.

Getting In Touch

As always we’d love to hear from you about your experiences. And we are always available to help with issues you may encounter. You can contact us in a variety of ways:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

Today we released the hotfix version 1.4.1 to address this issue so that the Add-on Builder can push a 1.4 version of the SDK to users. The patch included in the 1.4.1 release gets the version number, if absent from git, from the name of the parent directory.

If you were already using 1.4 in your own environment, you will not need this new version, nor would you see any differences if you decided to upgrade to it. This fix is strictly to help the Builder team launch 1.4 to their users.

If you have any questions or issues with this hotfix release, please ask in any of the following areas:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

For more information on the Jetpack Project check out our wiki

- Thanks to community members Hernan Colmeiro and Erik Vold, we have a new Simple Prefs API allowing you to easily create preferences for your add-on. Please see the documentation to learn how to use this new API.

- We have a brand new loader which is simplified and should give us even better performance.

- We have a new layout to the XPI files generated by the SDK. *Please note this if you have hard-coded any resource://URL links!! You should fix those links as specified in the release notes!*

For more new features and known issues,please see the Release Notes.

To get started building add-ons with the Add-on SDK, download it, then check out the documentation!

As always, we’d love to hear from you about your experiences with this release. You can contact us in a variety of ways:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

For more information on the Jetpack Project check out our wiki

- Fixed a bug where panel-based content scripts don’t work after reloading or changing location
- We now officially support Python 2.7
- Loads of changes and additions to the Add-on SDK documentation

For more details about these and other new features and fixes, please see the Release Notes.

To get started building add-ons with the Add-on SDK, download it, then check out the documentation!

As always, we’d love to hear from you about your experiences with this release. You can contact us in a variety of ways:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

For more information on the Jetpack Project check out our wiki.

This version of the SDK, like 1.1, contains mostly stability work and bug fixes. This release also includes:

• The ability to reload a tab via a new reload method in the tabs module
• The self module now contains a “name” and “version” allowing one to identify their version of the Add-on SDK
• SDK modules will now display in the about:memory page showing their memory consumption

For more information about these and other new features, please see the Release Notes.

To get started building add-ons with the Add-on SDK, download it, then check out the documentation!

As always, we’d love to hear from you about your experiences with this release. You can contact us in a variety of ways:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

For more information on the Jetpack Project check out our wiki

This is still the plan, but for our first attempt we noticed some things that were wrong with the plan as we currently have it and would like to propose a way of getting past these problems and getting to a new repack process.

What Went Wrong

The first problem we faced is that the repacker is the first service to use AMO’s brand-new APIs for updating add-ons, and we hadn’t tested the interaction between the two sites sufficiently beforehand, so we had to implement fixes for issues we encountered during the repack testing, which slowed down the testing.

Second, our testing was short and not deep enough for what we were trying to accomplish. The repack team didn’t get enough testing in themselves, nor did they make it possible for other project participants to test repacks and suggests issues and fixes before the production run of repacking.

Finally, what we are fundamentally trying to do is repackage a derived format without the source code it came from as reference, like decompiling a program, making changes, and then recompiling it. This is something that is hard to do and as it turned out, didn’t work very well. We could fix that by including the source code in the XPI. However, including the source code in the XPI would defeat our goal of making the XPI size as small as possible (this is extremely important for mobile versions of Firefox).

A Proposal

So what can we do about these issues? First of all, the repack team will answer the testing problems by starting testing earlier and sharing the results with everyone. In addition, the use of the AMO APIs is now solved as the calls we are using are now verified and tested.
However, the issue about the required sources for a clean rebuild is a bit more difficult and needs a new proposal.

Short-term

In the short-term I propose that we only repack add-ons which are built using the Add-on Builder. This is the quickest and safest solution as we have access to all the sources with Builder-based add-ons. The repack process is much simpler too as we don’t have to unpack a XPI first. For those who use a local installation of the Add-on SDK to build an add-on, we will document how to repack your add-on and the process for pushing the new one to AMO. In addition, you can move your add-on to the Add-on Builder and take advantage of the automatic repacks if you’d like, but do keep in mind that the Add-on Builder is still in beta at this point.

Long-term

The long-term solutions will need to be studied and debated a bit more. One option we have is to create a “source package” that can be pushed to AMO for use in repacking. However, this would mean that AMO would have to store these source packages and generate XPIs from them in addition to taking on responsibility for repacking when a new SDK is released. Obviously this would involve adding a great deal of functionality to AMO, as well as tooling up the services side to store these new, larger packages.

Another option is to land parts of the Add-on SDK into Firefox itself, including API implementations and the module loader. If an API already in Firefox needs updating to maintain compatibility with changes to Firefox, we won’t need to repack add-ons that use that API, as the updates can be made to that new version of the browser rather than each individual add-on. Doing this has other benefits as well. For example, it may help reduce XPI sizes tremendously. However, this too would take a bit of time to implement and is thus a long-term solution.

At this point we think that the short-term solution of just repacking Add-on Builder-based add-ons would be the best approach. We would also provide documentation describing the simplest approach for repacking add-ons along with best practices and troubleshooting. In addition, we would look into how best to notify authors when their add-ons need to be repacked manually.

Still, we also want to know what you think about this as well as the long-term ideas. Please feel free to leave your comments here or on our jetpack discussion forum