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

• Addon SDK 1.4 shipped last week; if your SDK-based addon makes use of resource urls to access web content located in the data directory, please check out my blog post detailing the dangers of hard-coding these urls, and how you can fix them.
• Cheevos is an SDK-based addon written by Firefox developer Jared Wein that awards you achivements for getting to know Firefox better. Jared started working on Cheevos at the SDK Hack Day in November, and blogged recently about the progress the addon has made and the current leaderboards.
• Irakli recently moved and expanded the list of community-contributed modules; you can now find it on github.

Quick Stats

• Total open bugs: 241
• Bugs created last week: 17
• Bugs fixed last week: 6
• Total SDK-based Addons on AMO: 423
• Open pull requests on Github: 24

Note: the stats above are based on the queries I linked to for each item. If you have suggestions on how these queries might be made more accurate,please comment below. Stats generated at 2012-01-17 11:31:31 PST

Meeting Brief

• Builder: on track for 1.0 in February, the new builder helper addon needs testing.
• SDK: now licensed under MPL v2.0, releasing SDK 1.5 test build later today.
• Community feedback regarding confusing web presence, will look at ways to consolidate info.
• Discussion on the priorities and next steps for user contributed modules, widget in toolbar feature, addontab.
• Alex’s builder re-write needs review.

Full minutes are available here:
https://wiki.mozilla.org/Labs/Jetpack/Weekly_Meeting/2012-1-17#Minutes

• We released SDK 1.4 today which includes important new features including a new module loader implementation, as well as the simple-prefs module.
• Wladimir Palant blogged about measuring memory usage of SDK-based addons using some of the new memory reporter features.

Quick Stats

• Total open bugs: 235
• Bugs created last week: 17
• Bugs fixed last week: 11
• Total SDK-based Addons on AMO: 401
• Open pull requests on Github: 24

Note: the stats above are based on the queries I linked to for each item. If you have suggestions on how these queries might be made more accurate,please comment below. Stats generated at 2012-01-10 10:28:34 PST

Meeting Brief

• Builder: release tomorrow fixes AMO account ids, looking for feedbackon Builder helper addon
• SDK: releasing 1.4 today, working to co-ordinate messaging resource uri value changes
• Apps: consult with labs to see which api-utils modules they would like frozen
• Talos testing: Jeff Hammel stopped by, kicking off project to get automated testing

Full minutes are available here:
https://wiki.mozilla.org/Jetpack/Weekly_Meeting/2012-1-10#Minutes

- 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

More Details
The last few weeks, Mozilla IT has addressed numerous stability issues with AMO and VAMO (versioncheck.addons.mozilla.org, which handles add-on update pings) and made significant changes to the network configuration to keep AMO up and running. One of those changes was the addition of a caching proxy in our Amsterdam datacenter, which was brought online on December 16 to receive 1/3 of the update ping traffic.

Unfortunately, these new servers were not configured to send their logs to our metrics processing tools, so those pings were not counted and the logs are no longer available. We were not immediately sure of the scope of the problem due to both the ongoing stability issues and expected decline in usage during the holidays and fluctuation in usage after a release. The log configuration was corrected yesterday afternoon and Metrics is validating today whether the logs are being processed correctly going forward.

Mozilla IT and Metrics are working on automated ways to prevent this from happening in the future as we continue to deploy AMO around the world. We know that many developers depend on these statistics, and apologize for the data lost over the past 2.5 weeks.

• Happy New Year!
• Matteo Ferretti recently landed initial mobile support for the page-mod module in pull request 301 Watch this space for additional posts on creating mobile addons with the SDK!
• Dietrich Ayala blogged about the Firefox Features effort, and the current plans for pushing this SDK-related project forward in 2012.
• We’re working with the Mozilla automation team to automate SDK performance tests.

Quick Stats

• Total open bugs: 235
• Bugs created last week: 4
• Bugs fixed last week: 5
• Total SDK-based Addons on AMO: 366
• Open pull requests on Github: 27

Note: the stats above are based on the queries I linked to for each item. If you have suggestions on how these queries might be made more accurate,please comment below. Stats generated at 2012-01-03 11:08:08 PST

Meeting Brief

• Q4 re-cap: most goals are in good shape, need to blog about them, in particular mobile page-mod support.
• Mossop is working with the Automation test to get automated performance tests running this quarter.
• Changes in Firefox 10 have changed how arrays are treated when passed into content scripts, we need to adjust SDK code to account for this. This is now a blocking issue for 1.4
• Flightdeck: looking towards scheduled 1.0 launch and 2012 roadmap, co-ordinating with Alex to fix issues in the current builder helper add-on.
• Hidden window research is promising.

Full minutes are available here:
https://wiki.mozilla.org/Jetpack/Weekly_Meeting/2012-1-3#Minutes

• Louis Remi Babe wrote two excellent posts on working with content scripts in the SDK and using jQuery in content scripts.
• The simple-prefs API has landed on the SDK’s master branch and we need your feedback! Here’s how to get started.
• Jorge Villalobos recently ran some tests measuring the impact of the SDK on Firefox start-up time, with great results!

Quick Stats

• Total open bugs: 231
• Bugs created last week: 19
• Bugs fixed last week: 8
• Total SDK-based Addons on AMO: 383
• Open pull requests on Github: 30

Note: the stats above are based on the queries I linked to for each item. If you have suggestions on how these queries might be made more accurate,please comment below. Stats generated at 2011-12-13 10:32:47 PST

Meeting Brief

• Builder: hotfix release on Monday to fix save issues, Wednesday’s regular release includes save fixes as well as new search tags for ‘example’ and ‘featured’, as well as super user support.
• SDK: Q4 goals are on track!
• Some discussion on automating performance testing of the SDK, including some advice from Dietrich on how is work in the cedar tree could be adapted to this.

Full minutes are available here:
https://wiki.mozilla.org/Labs/Jetpack/Weekly_Meeting/2011-12-13#Minutes

The results were very favorable this time, with the
empty add-on adding only 1.8% (11ms) to startup, and Infocon adding only
3.6% (22ms), on average. As a reference point, after our initial tests
we decided that 7% was roughly the line where add-on startup overhead
stopped being “Excellent” and began being just “Good”.

The methodology of these tests was to measure Firefox start-up time under three different scenarios:

1. using a clean profile with no addons enabled.
2. with a single ‘empty’ SDK-based add-on enabled.
3. with a non-trivial add-on enabled.

The great thing about this is that we now have solid data that indicates SDK version 1.3 itself has little effect on Firefox start-up time however, as Jorge suggests, there is much more testing that could be done. In particular, we should continue to run these tests to ensure that future versions of the SDK do not degrade start-up performance as we add new modules or make infrastructure changes to the SDK.

If you’re curious, we test start-up impact using Talos according to this methodology:

https://developer.mozilla.org/en/Measuring_Add-on_Startup_Performance

If you want to run the tests yourself, Talos is relatively straightforward to set up:

https://wiki.mozilla.org/StandaloneTalos#How_to_set_up_Talos_for_testing_at_home

I should warn you that the tests themselves can take quite some time to complete!

• As Justin Scott noted here, addons.mozilla.org was down yesterday for some time or was responding very slowly. This seems to have been resolved but Mozilla IT is continuing to monitor the situation.
• We will be releasing the first beta build of Addon SDK 1.4 some time today. Watch for announcements on the google group.

Quick Stats

• Total open bugs: 221
• Bugs created last week: 11
• Bugs fixed last week: 8
• Total SDK-based Addons on AMO: 373
• Open pull requests on Github: 21

Note: the stats above are based on the queries I linked to for each item. If you have suggestions on how these queries might be made more accurate,please comment below. Stats generated at 2011-12-06 14:00:27 PST

Meeting Brief

• Flightdeck: new release this week including many search enhancements. Will be publishing draft roadmap later today.
• SDK: Q4 goals review, 1.4b1 will be spun today.
• UX team dropped by to talk about upcoming UX changes that affect how addons appear in Firefox.
• discussions next week in SF to talk about the SDK Roadmap for 2012.

Full minutes are available here:
https://wiki.mozilla.org/Labs/Jetpack/Weekly_Meeting/2011-12-6#Minutes