Add-ons Blog

Announcing Add-on SDK 1.5!

by Dave Mason

5

under jetpack, sdk

The Jetpack team is pleased to announce the release of Add-on SDK version 1.5! This version of the SDK has two major new features as well as many smaller ones and some important bug fixes.

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

Using Javascript ( *.jsm ) modules in the SDK

by Jeff Griffiths

7

under developers, jetpack, sdk

The ability of developers using the SDK to get chrome authority and access xpcom services is a key feature. The SDK was designed from the start with the assumption that some developers will always need access to the underlying Mozilla platform. While xpcom is the main way to access low level apis, a lot of functionality in Firefox is instead implemented as JavaScript Modules, and can be used in your code much more naturally than xpcom services because they are just JavaScript, and from a design perspective quite similar to CommonJS modules.

Here’s a code snippet that you can use to import a jsm into your code:

const { Cu } = require("chrome");
 
let AddonManager = Cu.import("resource://gre/modules/AddonManager.jsm").AddonManager;
 
AddonManager.getAddonsByTypes(["extension"], function(addons) {
    var addonData = [];
 
    for (let i in addons) {
		let cur = addons[i];
		addonData.push({
			id: cur.id.toString(),
			name: cur.name,
		});
	};
	console.log(JSON.stringify(addonData, null, '   '));
});

Read the rest of this entry »

The Add-on Review Queues are empty!

by Jorge Villalobos

22

under contests, developers, general

Thanks to the tireless efforts of the AMO Editors group, we have reached an important milestone that hasn’t been reached in years (or ever, probably). All add-on review queues are currently empty.

Add-on review queues - all empty!This means that if you submit your add-on now or in the following days, chances are it will be reviewed within a few minutes. This is amazing feat, specially considering that add-on submissions are constantly increasing, and we add new policies all the time that make add-on reviews higher quality, but also longer to perform.

We’d like to thank and congratulate the AMO Editors team for their exceptional work along the years. You guys are amazing! We’ll call out our most active contributors soon, when we wrap up the very successful New Year’s Challenge.

PS: If you’re an add-on developer and your add-on hasn’t been reviewed, please get in touch with us by commenting here. It’s possible that your add-on is in an Incomplete state and you forgot to add it to one of the queues, or it could be a bug on our site.

Can’t make the SF Meetup? Catch it on Air Mozilla!

by Amy Tsay

0

under builder, developers, events, jetpack, sdk

The Add-ons meetup in San Francisco is less than a week away, so be sure to RSVP if you haven’t already.

If you’re interested in seeing how easy it is to create add-ons for Firefox with Add-on Builder and the Add-on SDK but can’t make the event, we are broadcasting it on Air Mozilla from 6:30-7:30pm.

Hope you can join us!

Date: Tuesday, February 21, 2012
Time: 6:00 – 8:00pm
Location: Mozilla SF – 2 Harrison Street, 7th Floor

Jetpack Project: weekly update for February 14th, 2012

by Jeff Griffiths

0

under builder, events, jetpack, releases, sdk

Project News

  • Next week’s Bay Area Firefox Add-ons meet-up will be at Mozilla’s San Francisco offices on Tuesday, February 21 at 6PM. This month’s meetup features the SDK and Builder, including a talk by yours truly, a raffle for an Android Tablet and much, much more! If you’re in the area on Tuesday Feb 21 at 6pm PST and want to attend, RSVP here.
  • The entire Jetpack team will be meeting up for a work week in Mozilla’s Mountain View office next week to work together and plot out the future!

Quick Stats

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-02-14 15:10:53 PST

Meeting Brief

  • Builder: working on blocker bug prior to releasing 1.0, testing a patch now.
  • SDK: releasing 1.5 next week, still working on several important bugs, also 1.5 will require a re-pack.
  • Dietrich provided an update on project to deliver new Firefox features as add-ons.

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

Bay Area Add-ons meetup: Got a demo?

by Jeff Griffiths

0

under builder, events, jetpack, sdk

I’m excited to be working with Amy to resurrect the bay Area Add-ons meetup next Tuesday night. The theme for this month’s meetup will be the Add-on SDK and Builder, so I will be giving brief overviews of how these tools work and the kinds of things you can do with them.

We’d also like for people to show up and show off their own add-ons, so if you’re interested in giving the group a short demo of a Firefox add-on you’ve been working on, send me a tweet at @mozillajetpack!

Remember: One lucky raffle winner will receive an Android tablet!

Date: Tuesday, February 21, 2012
Time: 6:00 – 8:00pm
Location: Mozilla SF – 2 Harrison Street, 7th Floor

Add-ons Update – Week of 2012/02/09

by Jorge Villalobos

2

under compatibility, developers, documentation

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

  • Most nominations for full review are taking less than 5 days to review.
  • Most updates are being reviewed within 3 days.
  • Most preliminary reviews are being reviewed within 3 days.

These stats are taken from last week’s queue report:

  • 21 nominations in the queue awaiting review.
  • 25 updates in the queue awaiting review.
  • 9 preliminary submissions in the queue awaiting review.

Our New Years Challenge has really paid off and add-ons are now reviewed almost immediately after they are submitted. Most add-ons waiting in the queue are waiting for actions from admin reviewers or their developers.

If you’re interested in joining the AMO Editors team and help us review add-ons, please visit our wiki page.

Test Your Add-ons for Memory Leaks!

The MemShrink team was assembled some time ago to work on reducing Firefox’s memory footprint. Many memory bugs have been filed and fixed for Firefox, but add-ons are also a significant factor in how much memory is being used.

There is an ongoing effort to track and stomp memory leaks in add-ons. Here’s where you can help, either by testing the add-ons you created, or testing the add-ons you use. Please read the article on Zombie Compartments, particularly the add-ons section. It should give you some pointers on how to find leaks and how to avoid them. The short version is don’t hold any references to DOM objects after the document is closed.

The AMO review team is already aware of this, and we have added memory leaks to our testing policies. Add-on versions that leaks may not get full review.

If you have any questions about this, post them in the comments.

Firefox 11

The Firefox 11 compatibility blog post is up now.

The compatibility bump will be run very soon, but it will be run differently than last time. Since Firefox 10 an above have add-on compatibility turned on by default, there’s no longer a need to do maxVersion bumping. So, we’re going to do run the usual compatibility checks, but only email developers if their add-ons don’t pass some of the checks. These add-ons that don’t will also be added to the compatibility override list so users know they are incompatible, provided that the compatibility bug really causes problems in the way the add-on works.

Firefox 12

Firefox 12 already hit the Aurora channel, so the compatibility updates should be coming soon.

Jetpack Project: weekly update for February 7th, 2012

by wbamberg

1

under builder, developers, jetpack, sdk

Project News

  • We released a hotfix release, 1.4.3. It fixes an important regression in 1.4, 1.4.1 and 1.4.2 and should be taken by anybody currently using one of those releases. More details here.
  • FOSDEM happened, there were Jetpack presentations and discussions. Henrik Skupin blogged about it, and contributed a patch.
  • Andrew Sutherland has written an add-on using the SDK to break down Firefox memory usage by tab: or, to “help you lay blame more easily”

Quick Stats

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-02-07 17:43:52 PST

Meeting Brief

  • The Add-on Builder is preparing for its 1.0 release. We have one blocker, bug 724766, otherwise things are looking good.
  • We had a brief 1.4.3 postmortem: concluded that we need to improve test coverage for beta releases.
  • There’s a lot of demand to make the SDK support Thunderbird. The SDK team does not have the resources to support Thunderbird officially, but should not prevent Thunderbird from working by, for example, throwing an exception when Thunderbird is detected.
  • Here’s a blog post from Dietrich on using the SDK to deliver features into Firefox.

Full minutes are available here:

https://wiki.mozilla.org/Jetpack/Weekly_Meeting/2012-2-7#Minutes

SF Meetup: Add-ons Made Easy with Builder and SDK

by Amy Tsay

0

under builder, developers, events, jetpack, sdk

If you’re in the Bay Area, we invite you to join us at our San Francisco office on Tuesday, February 21, for an evening of food, drinks and good company!

Come and see how easy it is to create add-ons for Firefox with Add-on Builder and the Add-on SDK. If you’re a Web developer and know HTML, JavaScript and CSS, you already have what it takes to make great add-ons.

One lucky raffle winner will receive an Android tablet!

Date: Tuesday, February 21, 2012
Time: 6:00 – 8:00pm
Location: Mozilla SF – 2 Harrison Street, 7th Floor

** Reserve your spot now! **

Add-on SDK 1.4.3 Released

by Dave Mason

2

under general

We have identified a serious bug in the 1.4.* releases, and have made a hotfix release of the Add-on SDK. The hotfix release is version 1.4.3.

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:

screenshot of adding recovery library

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