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 »
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.
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.
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
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
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
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.
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
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! **
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:
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). 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"
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
For this post, please welcome guest blogger and SDK developer Matteo Ferretti who has been hard at work porting the SDK to work with the new native version of Mobile Firefox.
Getting Started
Add-on SDK version 1.5 is due to be released on February 21st, and we're pleased to announce that this version will introduce initial support for creating addons for the new native version of Firefox Mobile (codename "fennec").
Mobile support is still experimental and is currently focused on addons using the SDK's page-mod module to alter and interact with web pages.
If you're interested in trying this support out now, you can do so by checking out the ‘master’ branch of the addon-sdk repository:
git clone git://github.com/mozilla/addon-sdk.git
Alternatively you can just download a zip archive of the current master:
https://github.com/mozilla/addon-sdk/zipball/master
Developing an add-on for Firefox Mobile with the Add-on SDK is very similar to the desktop. If you're not familiar with Add-on SDK development process, you can take a look here. It helps but is not mandatory for this tutorial.
Getting set up
In addition to having the correct version of the SDK, there are some additional requirements:
you need to have an Android device connected to your computer via USB on the Android device, you need to install a Nightly build of Firefox Mobile. you need to download and install the Android SDK, including the SDK Tools. Specifically, the SDK requires that you have installed the 'adb' command-line tool.
Please see this detailed tutorial by Aaron Train for more information on installing and configuring the Android SDK.
Now you're ready to write the classic "Hello World" example!
Hello, Fennec!
Firstly, be sure that you have connected your device to your computer. You can check it running from a shell the following command:
adb devices
Then, be sure that you don't have any Firefox Mobile already running. That is important because the Add-on SDK will run your add-on using a temporary firefox profile for development, not the default one. If Firefox is already running, you can quit Firefox by opening the application menu, selecting 'More', then selecting 'Quit'.
Don't worry, if Firefox is running the Add-on SDK will clearly warn you.
Now open a shell, navigate to the Add-on SDK root directory, and execute:
source bin/activate
This will activate the SDK's environment and allow you to run the cfx tool from the current shell prompt nomatter what directory you are currently in..
Change to another directory and then create a directory called hellofennec. Keeping your add-on code outside the SDK is good practice. Navigate to that directory and run cfx init to create a new addon:
mkdir hellofennec
cd hellofennec
cfx init
With a text editor or IDE of your choice, open lib/main.js, and replace its contents with the following:
console.log("Hello, Fennec!");
Save it. You're ready to run it on your device using the following command:
cfx run -a fennec-on-device -b ~/path/to/adb --mobile-app fennec --force-mobile
And yes, compared to the desktop version the mobile version needs more arguments. You can learn about all the cfx's arguments just run it without any parameters, but let's have a quick look about what they means in this context:
-a, –app : specify the application that runs the add-on, in this case "fennec on device".
-b, –binary : is mandatory for fennec-on-device app. SDK needs to know where you have installed the adb tool that is installed with the Android SDK in order to communicate with your device. So, replace this value with the right path where you have installed the adb platform tool.
–mobile-app : is the name of the Android intent. If you have only one Firefox Mobile version installed on your device, you can omit this option. The value for nightly is fennec, for aurora this is fennec_aurora, for beta this is firefox_beta and for release this is firefox.
If you have a Fennec's custom build on your device, the intent's name is fennec_<your_username> by default.
–force-mobile : this flag will be removed when the mobile's support will be stable and not experimental anymore.
When you execute the command the first time you'll see a message like this:
No 'id' in package.json: creating a new ID for you.
package.json modified: please re-run 'cfx run'
Run the command again, and it will run Firefox Mobile on your device with your add-on installed.
Congratulations! You have made your first step in mobile add-ons development with Add-on SDK!
Hack the web
As I said previously, Add-on SDK provide a minimal support for mobile at the moment, focused mainly on page-mod. In short, they are add-ons that can modify any — or a specific — web pages loaded by the browser.
On mobile this is very handy. For instance, you can optimize a website that it wasn't designed for mobile devices, improve the readability, or adding unique functionality.
For this tutorial I made a simple add-on that "mod" the famous penny-arcade.com website. You can check it out from github:
git clone git://github.com/ZER0/penny-arcade-comics.git
Alternatively, you can download it as zip archive.
What it does is simple: when you're on the penny-arcade.com homepage or reading a news post, switching from portrait to landscape will display the webcomics related to that news, without clicking a link and zooming (landscape fits more the format of penny-arcade comics than portrait, and portrait is more suitable to reading news). Switching back from landscape to portrait will hide it again.
A deeper look
So, how it works? The important files are data/content.css, data/content.js and main.js. The first two are the files injected into penny-arcade.com, and the last one is our add-on entry point.
Let's start with main.js.
Firstly, we require the Add-on SDK modules needed:
var PageMod = require("page-mod").PageMod;
var data = require("self").data;
The PageMod object allows us to create a page-mod; and data object provides an access to the data directory's files.
PageMod({
// page-mod will added only on the homepage and news page of penny-arcade.com,
// with or without www as prefix.
include: /^http:\/\/(www\.)?penny-arcade.com(\/|\/\d{4})?.*/,
contentScriptFile: data.url("content.js"),
contentScriptWhen: "ready",
onAttach: function (worker) {
worker.port.emit("init", data.url("content.css"));
}
});
For the main.js, that's all. The addon will load content.js into the page when the DOM is ready for any URL that matches the include property's regular expression. When the page-mod is "attached" to a document, the onAttach callback will emit a custom init event to the content script, passing the URL of content.css.
So, what happens on the other side when the init event is emitted? Let's see content.js:
self.port.on("init", function init(cssURL) {
// We're not interested in frames
if (window.frameElement) return;
addStyleSheet(cssURL);
var comicsPageURL = document.querySelector(".btnComic").href;
var http = new XMLHttpRequest();
http.open("GET", comicsPageURL, true);
http.onload = addComics;
http.send();
});
A page-mod is attached to every page that matches the include rule, so frames as well. We are not interested in frames, only in the main page, so with:
if (window.frameElement) return;
We avoid to execute code in that specific case.
Then, we add the stylesheet given using addStyleSheet function, defined in the same file, and we obtain the comics page URL by looking into the DOM.
Because the comic page and the news page are in the same domain, we can use XMLHttpRequest from the content script itself (content scripts follows the Same Origin Policy) instead of having to delegate this task to the Add-on code (that can perform Cross Domain requests).
When we receive the response, the comic page's image url is extracted and displayed in the current page. And that's all!
The behavior related to hide and display the comics image is implemented in css file using media queries:
@media (orientation:portrait) {
#penny-arcade-addon-comics {
display: none;
}
}
@media (orientation:landscape) {
#penny-arcade-addon-comics {
display: block;
}
}
See the results
Navigate into the penny-arcade-comics directory and run it. You should see Fennec Nightly or Aurora ( whichever you specified ) start up on your device. Next, open the Firefox menu, select 'More', then 'Addons'. You should see the list of default addons installed into Firefox, as well as two additions: 'Mobile Addon-SDK utility addon' and 'penny-arcade-comics'.
You can now see how it works at first hand by opening the Penny Arcade site ( http://penny-arcade.com/ ) in Firefox Mobile:
Portrait

Landscape

If you do not have an Android device to test this on, you can still see the effect by installing this addon on Firefox Desktop and re-sizing the window to trigger the media queries we've used in our customer css.
When running the addon on your deivce, you will notice that your shell will be full of javascript warnings; this is because cfx will dump all of Firefox's log messages there. They can be useful, but especially when you work with page-mod it's easy lost your add-on's logging information in this flow. What I usually do instead is open a new shell, and execute a command like that:
adb logcat | grep info:
So, in the shell where cfx is executing I will get all the messages, and in the other one I filtered out only the messages from the add-on.
Conclusion
We're very excited about the possibilities around mobile addons and would love any feedback you might have. Working with the Android SDK currently is a bit awkwards, admittedly. If you do get started creating your own addons for Fennec Nightly, please keep in mind that not all SDK modules work properly.
The modules that currently work are:
page-mod page-worker request self simple-storage timers
There are additional modules that mostly work; we are currently working on providing as much support for mobile as possible and will keep you up to date on our progress.