Add-ons Blog

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

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

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

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

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

Mobile Add-on development using the Add-on SDK

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.

Renaming Personas

Firefox users love Personas. They’re a fun and easy way to customize Firefox and make it your own. But in talking with new users, we’ve learned that they are often confused by the name and don’t quite get that Personas are just another way to theme your browser. And more often than not, when a Firefox user describes the look of their browser, they use words like “wallpapers” or “backgrounds” instead of the proper name Personas.

We’ve heard questions from many users over the years as to why we kept the Personas name, and even ran tests that showed users are more likely to try out Personas when called by a different name. “Persona” is a good name, but is probably better suited for a different product in the future.

So, we’d like to rename Personas to something more understandable and localizable. And we’d love your help.

We’ve come up with several options for a new name and want to know what you think. Please take a look at the poll below and submit your vote by Wednesday, February 8. Your choice will play a big role in which name we choose, as well as other factors including the word’s meaning in other cultures and languages.

We expect this transition to take place over the coming weeks. Thanks for your help, and please let us know if you have any questions or comments.

VOTE NOW

Jetpack Project: weekly update for January 31st, 2012

Project News

  • We released two point releases, 1.4.1 and 1.4.2 to address issues related to deploying SDk 1.4 on the Add-on Builder site.
  • Jorge pointed out an important compatibility issue with SDK 1.3 and the upcoming Firefox 11 release in his compatibility post. We will be re-packing add-ons built with 1.3 and lower prior to the release of Firefox 11, but in the meantime you should base all current and new releases on SDK 1.4.
  • There were a couple of community-developed modules discussed on the google group this week, including madarche’s OrderedMap implementation and Ben Buksch’s collections module. This is exciting to see, particularly because they are now collaborating on a single implementation.
  • Looking forward to participating at FOSDEM this weekend!

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-01-31 11:30:03 PST

Meeting Brief

  • Add-on Builder: continuing to prepare for 1.0 release, next steps include refreshing vide content on AMO and bug fix releases over the next 2 weeks.
  • SDK: released 1.4.1 & 1.4.2 to address Builder integration issues, 1.5b3 is being spun this afternoon.
  • Round table: need to discuss and clarify 3rd party module integration path into core, in particular where to publish proposals.

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

Add-ons @FOSDEM 2012

Tomorrow I’m heading to Europe for a week or so; amongst other things I am very very excited to be attending FOSDEM for the first time after hearing about it for years! I’ll be speaking and generally helping out in the Mozilla project’s dev room. If you are at all interested in add-on development, there are a number of interesting talks & events you should attend:

Please check out the full talk schedule for the Mozilla dev room, there are many great talks scheduled on such diverse subjects as Android start-up performance, agile community building and WebFWD. You should also look over the FOSDEM 2012 pages on the Mozilla wiki as our community coordinator Benoit Leseul has provided tons of useful information there.

I am also going to try to organize a couple of additional happenings during the weekend:

  • dinner on Saturday night! If you want to come out with us to sample some local food and talk about Add-on & Firefox development, drop by the Mozilla room as we wrap up the day at 7PM on Saturday.
  • an Add-ons BOF on Sunday afternoon. FOSDEM is providing two rooms for BOFs this year, so I will try to schedule a convenient time as soon as I can and will put up signs announcing the time & place in the Mozilla room as well as at the Mozilla booth.

Add-on SDK Version 1.4.2 Released

Following hot on the heels of yesterday’s release of 1.4.1, we identified an issue in the SDK where console logging was not happening correctly. Through discussions with the Add-on Builder team, this issue was identified as a Priority 1 blocker for the Builder team given the recent addition of 1.4 support earlier this week. If you’re curious, the tracking bug for this issue is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=718230

While this issue primarily affects the Builder, it will also affect any addons packaged using 1.4.0 & 1.4.1 that print debug statements to Firefox’s console window using console.log. Using console.log to print debug statements to the terminal when running an addon using the cfx tool is not affected by this issue.

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

For more information on the Jetpack Project check out our wiki

Add-on Compatibility for Firefox 11

Firefox 11 was pushed to the Aurora channel weeks ago, and Firefox 12 will follow suit very soon. So, it’s time for the long overdue overview of bugs that can affect add-on compatibility in Firefox 11. I’m sorry this update is being posted so late, but things have been pretty crazy lately. More on that in the Firefox 10 section.

A few notes regarding Firefox 10

If everything goes according to plan, Firefox 10 will be pushed to the public in less than a week. There are a couple of points that are worth mentioning:

  • Starting with Firefox 10, add-ons will default to compatible. All add-on versions that have compatibility up to Firefox 4 or higher will automatically work in Firefox 10 and all future releases. This excludes add-ons that are not extensions (themes, dictionaries, language packs) and add-ons with binary components. We will also keep an override list that we will fill with all add-on versions that are known to break due to compatibility problems. This is what has kept me busy for the past weeks. We need your help to keep the override list up to date.
  • Rename omni.jar to omni.ja. If your add-on references omni.jar directly, it will break now that it has been renamed. We recommend that you find more flexible ways to reference these files, since most should be accessible through chrome URLs.

For more information about Firefox 10 compatibility, please read the full compatibility update.

Firefox 11

Other important changes are noted in Firefox 11 for developers.

New stuff in 11!

Please let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 10 or 11, I’d like to know.

Because of the Default to Compatible feature, we are no longer doing compatibility bumps like we did before. We will still run the validation but only send you a message if your add-on is identified as incompatible. There will be no more automatic version upgrades, given that there’s no point anymore.