Unless you’re hiding under a rock, you are probably aware that the Mozilla Project has released Firefox 21 today. Additionally, unless you’ve been completely ignoring my recent posts on this blog, you might also realize that Firefox 21 signals a new chapter in the life of the Jetpack project, as we ship the SDK’s module loader and APIs in Firefox 21.

To me this is a big deal, for add-on developers, for Firefox developers, for the entire project. I’d like to thank everyone involved for all the hard work, but in particular there are a few people who deserve special mention:

• Atul Varma & Aza Raskin started Jetpack in 2009 in Mozilla Labs, then rebooted it in 2010, ushering in the modern era of content scripts, CommonJS modules the command-line cfx tool and Add-on Builder.
• Dietrich Ayala, David Mason, Myk Melez & Brian Warner who guided the project through the ‘re-boot’ phase, always with an eye to landing Jetpack’s capabilities in Firefox and revolutionizing how Firefox features are made.
• Dave Townsend, Irakli Gozalishvili and the rest of the current Jetpack team who have done a ton of work coordinating a series of important changes to make the SDK fit nicely into mozilla-central.
• Various Mozilla Labs engineers including Shane Caraveo, Anant Narayanan, Andrew Sutherland & David Ascher who kicked the tires and built prototyped their own crazy ideas based on our shaky prototypes and beta releases.
• Our fantastic contributors who keep showing up with great code for new features and bug fixes.

Now that we ship with Firefox I have decided to dial back the frequency of these posts to every 6 weeks on uplift and instead highlight for developers the new features and bug fixes that have landed in the recent Nightly cycle. As always if you have questions, feedback or want to get involved you can find us on the wiki, on the email list and of course in #jetpack on irc.mozilla.org.

Quick Stats

• Total open bugs: 505
• Bugs created last week: 15
• Bugs fixed last week: 13
• Total SDK-based Add-ons on AMO: 1,809
• Open pull requests on Github: 54

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 2013-05-14 10:39:08 PDT

Help out Jetpack by using Stack Overflow! You may not be aware, but one of the most common sites where people ask questions about the Add-on SDK is actually on Stackoverflow.com. Questions are marked with the [firefox-addon-sdk] tag, and several new ones appear each week. While you are there, you should also check out the many questions tagged with [firefox-addon] as well. If you’ve got questions about add-on development yourself or don’t mind helping others, Stack Overflow is a great place to contribute.

Quick Stats

• Total open bugs: 522
• Bugs created last week: 45
• Bugs fixed last week: 19
• Total SDK-based Add-ons on AMO: 1,706
• Open pull requests on Github: 48

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 2013-04-09 08:23:50 PDT

Meeting Brief

• we’ve landed the final work to make Panels work with per-Window private browsing, to be released in Firefox 22.
• we’re close to landing platform support for cross-domain xhr in content scripts
• the Firefox team dropped by to talk about collaborating on new Add-on friendly features in Australis.

Full minutes are available here:
https://wiki.mozilla.org/Jetpack/Weekly_Meeting/2013-04-09#Minutes

After last Tuesday’s release of Add-on SDK 1.14, we updated you on Wednesday about changes in console.log behaviour, and then again on Thursday once we’d updated the AMO Validator and Add-on Builder sites to correctly support SDK 1.14. The current status is that we’re tracking a bug in the AMO validator which produces two erroneous warnings from add-ons packed with SDK 1.14. We expect the validator will be updated to fix this on Thursday afternoon ( PST ).

Quick Stats

• Total open bugs: 506
• Bugs created last week: 45
• Bugs fixed last week: 24
• Total SDK-based Add-ons on AMO: 1,696
• Open pull requests on Github: 47

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 2013-04-02 11:39:07 PDT

Meeting Brief

• High priority: Irakli is closing out Panels support for Fx22, cross-domain work is moving ahead, other items are on track.
• SDK: Wes proposes new Firefox-version-centric tagging scheme for > 1.14.
• Roundtable: dcamp is changing the devtools to use Jetpack’s loader, is looking for alternatives to his chrome url hack

Full minutes are available here:
https://wiki.mozilla.org/Jetpack/Weekly_Meeting/2013-04-02#Minutes

The one caveat with using Add-on Builder with SDK 1.14 is that the behaviour of console.log changed. If you rely on the Error Console window to view messages from console.log, you have two options:

1. Change all calls to console.log to console.error, which will print out scary looking red messages in the Error Console’s ‘Errors’ tab
2. Follow the instructions detailed in my blog post from yesterday to ensure that any calls in your add-on code to appear as they previously did in the ‘Messages’ tab of the Error Console window.

We’ve logged a bug to improve this experience via an update to the Add-on Builder Helper add-on so this will not be an issue in the future.

In 1.14 we added some additional features to the console API and also set the default log level to “error” instead of “info” for add-ons installed into Firefox via the Add-on Manager and Add-on Builder Helper as well as tools like the Extension Auto-installer.

An unfortunate side-effect is that by default, developers using these tools will no longer see messages from console.log() in the jsconsole window.

We have provided the ability for developers to set preferences to control logging behavior both globally and for a specific add-on, and by setting one of these preferences you can override the default.

Logging levels

The console module now defines a range of logging levels:

1. all: log calls to any console method
2. debug: log calls to debug(), log(), info(), warn(), error()
3. info: log calls to log(), info(), warn(), error()
4. warn: log calls to warn() and error()
5. error: log calls to error()
6. off: log nothing

New Preferences

We have defined two new preferences, which set the logging level either globally for all SDK add-ons, or for a specific SDK add-on:

extensions.sdk.console.logLevel: this preference can be added to about:config to change the logging level of all installed SDK-based add-ons.

extensions.[extension-id].sdk.console.logLevel: this preference can be added to about:config to change the logging level of a specific add-on. This preference overrides the global preference.

The value for each preference is the desired logging level, given as a string. If neither preference is set, the logging level defaults to “error”.

Restoring the old behavior

If you want to restore the previous behavior in which console.log messages are visible in the error log, please do the following:

1. open about:config
2. right-click and select New -> String
3. for the preference name, enter ‘extensions.sdk.console.logLevel’
4. for the preference value, enter ‘all’
5. restart Firefox

Here is a screenshot of what the result should look like:

The Jetpack team released Add-on SDK 1.14 a few hours ago! This is a huge step on our journey towards integrating Jetpack with Firefox.

Quick Stats

• Total open bugs: 496
• Bugs created last week: 48
• Bugs fixed last week: 38
• Total SDK-based Add-ons on AMO: 1,678
• Open pull requests on Github: 42

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 2013-03-26 09:31:12 PDT

Meeting Brief

• High Priority work: need to scope further PWPB work, gabor has nearly landed cross-domain content script support, panel positioning looks good to land this week, and discussion of next quarters batch of high-priority work.
• SDK: we’re shipping software, also the tree is orange! On different branches, thankfully.
• Roundtable: discussion on how to handle target releases for cfx vs the SDK apis now that we’ve landed. Looks like we should create a ‘cfx’ bug component.

Full minutes are available here:
https://wiki.mozilla.org/Jetpack/Weekly_Meeting/2013-03-26#Minutes

As I’ve written previously, SDK 1.14 will be the last release of the SDK to include the SDK APIs. Once Firefox 21 ships the version of Firefox you are using will always have the latest and greatest version of the SDK apis. What is more, add-ons packed with Add-on SDK 1.14 will always prefer the APIs embedded in Firefox if they exist, providing a forward-compatibility benefit to developers.

We are working to update Add-on Builder and the Add-on validator on AMO within the next couple of days so that they properly support 1.14. I’ll update the mailing list and twitter once this work has been completed.

What’s new?

• Initial support for Per-window Private Browsing. Firefox 20 replaces the existing private browsing ‘mode’ with an new feature that allows users to open private windows. A significant amount of work has been done to make this work for SDK-based add-ons.
• Unique tab ids on both Android and Desktop Firefox, for easier tracking of specific tabs.

You’ll find much more detail about SDK 1.14 in the release notes.

Some interesting stats about this release ( from the Github history between the 1.13.2 & 1.14 tags ):

• 329 changes in 117 pull requests between tags 1.13.2 and 1.14
• Special thanks to our community contributors Brett Zamir, Cykesiopka, Dan Stevens, Dương, H. Nguyễn, Gregg Lind, Marc Chevrier and slash_at_ac.auone-net.jp

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.

• We are releasing SDK 1.14rc2 tomorrow, which will also likely be tagged tomorrow as the 1.14 release candidate. In addition to this we are coordinating with the Firefox team and release-drivers to ensure that the code in 1.14 is exactly the same as what we will release in Firefox 21. If you’re maintaining an SDK-based add-on, please help and test your code with ths new RC!
• Last week’s work week in Sunnyvale yielded all sorts of amazing work, look for a post over on hacks.mozilla.org tomorrow for the full details.
• Eddy blogged yesterday about his work on getting Firefox’s Browser Debugger working with SDK-based add-ons.

Quick Stats

• Total open bugs: 509
• Bugs created last week: 37
• Bugs fixed last week: 12
• Total SDK-based Add-ons on AMO: 1,646
• Open pull requests on Github: 47

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 2013-03-19 09:20:18 PDT

Meeting Brief

• PWPB support is complete, but 1.14 & Firefox 21 will ship with only partial support for Add-ons that opt in to work in Private Browsing mode.
• Cross-domain capabilities and Panel Positioning changes are close to landing, SDK 1.14 re-packs are on track, and we need to re-evaluate high-priority items as we move into Q2.
• SDK: 1.14 RC1 was released today – test! test!
• Roundtable: discussion on prioritizing deep integrators over work targeted at casual add-on developers.

Full minutes are available here:
https://wiki.mozilla.org/Jetpack/Weekly_Meeting/2013-03-19#Minutes

We’ve now figured out that we only need to repack add-ons that actually use the private-browsing module.

• If you don’t use private-browsing, you don’t need to do anything.
• If you use the private-browsing module in an add-on that’s hosted on AMO, then it will be marked incompatible with Firefox 20, and will need to be repacked with SDK 1.14 when SDK 1.14 is released. We will repack it with SDK 1.14 if we can, and you will need to repack it yourself if you can’t. We will email you to let you know whether you need to do anything within a couple of days of releasing 1.14.
  
• if you use the private-browsing module in an add-on that’s not hosted on AMO: then you will need to repack it with SDK 1.14, or it will start leaking your users’ private data from Firefox 20 onwards.

Update: since the original version of this post, we’ve decided to make repacking with SDK 1.14 mandatory. Add-ons which are not repacked with SDK 1.14 will be marked as incompatible with Firefox 20.

We’re running a project to automatically repack as many AMO-hosted SDK add-ons as we can. AMO-hosted SDK add-ons that we can’t repack, and SDK add-ons not hosted on AMO, will need to be repacked by their authors once SDK 1.14 is release on March 26.

We’ll have another blog post outlining the repacking plan soon.

Firefox 20 introduces major changes to the “private browsing” feature, which will affect add-ons developed using the SDK. This blog post explains what the change is, how the SDK is handling it, and what add-on developers will need to do as a result. In summary:

• if your add-on uses the private-browsing API, you must repack it when SDK 1.14 is released on March 26th if you want your add-on to work properly on Firefox 20.
• whether or not your add-on uses the private-browsing API, you must update it if you want your add-on to be able to see private windows on Firefox 20.

What’s per-window private browsing?

Up to and including Firefox 19, private browsing has been a global property for the entire browser. When the user enters private browsing, the existing browsing session is suspended and a new blank window opens. This window is private, as are any other windows opened until the user chooses to exit private browsing, at which point all private windows are closed and the user is returned to the original non-private session.

Firefox 20 introduces per-window private browsing. This means that private browsing status is a property of an individual window. The user enters private browsing by opening a new private window. When they do this, any existing non-private windows are kept open, so the user will typically have both private and non-private windows open at the same time.

How does the SDK handle this change?

Under the old, global, private browsing model, add-ons can handle private browsing as a simple binary condition: while private browsing is active, don’t store any user data. The SDK’s private-browsing API supports this by offering an isActive property to check whether the browser is in private browsing mode, alongside start and stop events to be notified when private browsing starts and stops.

Here’s an add-on that stores the titles of tabs the user loads, unless the browser is in private browsing mode:

var simpleStorage = require("simple-storage");
 
if (!simpleStorage.storage.titles)
  simpleStorage.storage.titles = [];
 
require("tabs").on("ready", function(tab) {
  if (!require("private-browsing").isActive) {
    console.log("storing...");
    simpleStorage.storage.titles.push(tab.title);
  }
  else {
    console.log("not storing, private data");
  }
});

The first SDK release to target Firefox 20 is SDK 1.14. This release updates the API to support per-window private browsing, and makes another important change: by default, SDK 1.14-based add-ons won’t see any private windows.

Repacking your add-on

Hiding private windows by default means that add-ons developers don’t need to update their code in order to respect per-window private browsing: all they need to do is repack their add-ons using SDK 1.14. The old API will log deprecation warnings, but will behave as if the user never enters private browsing:

• isActive will always be false, and start and stop will never be triggered.
• the add-on will never see private windows, or objects such as tabs that are associated with private windows
• page-mods will not be matched for private windows

You must repack your add-on though! If you don’t, it may not function correctly, and will leak user private data, because private windows will not be hidden. We’re working on a plan to help add-on developers repack add-ons with 1.14.

Updating your code

If you want to see private windows, you’ll need to set the following key in your “package.json”
file:

"permissions": {"private-browsing": true}

Once you do that, you’ll see private windows, so if you store user data, you’ll need to use the new API to respect private browsing.

SDK 1.14 replaces the existing API with a new function isPrivate() that takes an object – a window, tab, or worker – as a parameter, and returns true if the object is a private window or is associated with a private window. So to update the add-on above, we could do something like this:

var simpleStorage = require("simple-storage");
 
if (!simpleStorage.storage.titles)
  simpleStorage.storage.titles = [];
 
require("tabs").on("ready", function(tab) {
  if (!require("private-browsing").isPrivate(tab)) {
    console.log("storing...");
    simpleStorage.storage.titles.push(tab.title);
  }
  else {
    console.log("not storing, private data");
    // do something else...
  }
});

Working with Firefox 19

SDK 1.14 bridges the gap between the old global private browsing, in Firefox 19, and the new per-window private browsing, in Firefox 20.

Since SDK 1.14 needs to support both versions, the new private-browsing API is designed to work with global private browsing. When running on Firefox 19, isPrivate() will return true if and only if the user has global private browsing enabled.

Summary

If you have an add-on built with an earlier version of the SDK, this section summarises your options when SDK 1.14 comes out.

If you do nothing

• on Firefox 19 your add-on will continue to work fine: it will get results for isActive, start, and stop that track global private browsing, and you will be able to use them to avoid storing user private data.
• on Firefox 20 your add-on might not work at all. If it does, it will see private windows, but the old private-browsing API will not ever tell you that they are private, so you may leak user private data.

If you repack with SDK 1.14

If you just repack your add-on but leave the code unchanged:

• on Firefox 19 your add-on will continue to work as before: it will get results for isActive, start, and stop that track global private browsing, and you will be able to use them to avoid storing user private data.
• on Firefox 20 any of the old private-browsing functions (isActive, start, and stop) will log deprecation warnings. Your add-on won’t see any private windows or objects, such as tabs, that are associated with them (it will behave as if these windows just don’t exist). isActive will always be false, and start and stop will never fire.

If you update your add-on

If you update your add-on, by setting the “private-browsing” flag, and updating your code to use the new isPrivate() API:

• on Firefox 19 your add-on will work fine: isPrivate() will map on to global private browsing by returning true if and only if the user is in global private browsing mode.
• on Firefox 20 you’ll see private windows, and isPrivate() will tell you whether it’s OK to store user data associated with windows, tabs, and workers.

The next phase ( Firefox 23 & Up )

Shipping in Firefox does not mean that the SDK is ‘done’; quite the opposite! The team still needs to maintain the SDK’s APIs with future versions of Firefox. As I mentioned in my previous post we do expect this work will be simplified because we will no longer need to support a range of Firefox versions with the same code-base.

What are we going to do with all this spare time? I’m glad you asked! There are three key initiatives that I mentioned in our Roadmap that are top priorities for Jetpack in 2013:

Simple, Powerful Firefox UI integration

Based on Stephen Shorlander’s excellent mockups, we will be implementing a set of high-level, useful APIs that allow developers to integrate custom UI into Firefox navigation bar in a reliable an efficient way. There will be no markup, no need to manually handle unload. These APIs will be available to all add-on developers, not just those using the SDK.

Rapid Prototyping of Firefox features

One of the goals of the SDK has always been to help make Firefox feature development easier. We’ve come a long way towards helping this by embedding our powerful, module APIs and CommonJS loader into Firefox, but we think we can go even farther by easing the pain for not only creating feature prototypes but also shipping the tried and tested code-base the prototype becomes in Firefox all using a modern, modular approach.

Awesome tools for Add-on Developers

A key goal for the team is to help improve the developer experience for add-on developers. We believe the best way to approach this problem is to create great native tools that leverage the work of the already fantastic Firefox Developer tools and provide add-on developers with the features they’ve been asking for, such as debugging, rapid prototyping and in-browser packaging.

A related goal for the team is to continue to support Add-on Builder as we move through this transition. Next week I will publish a road-map for Add-on Builder that provides more detail about Builder’s future.