The Review Queues

• Most nominations for full review are taking less than 3 weeks to review.
• Most updates are being reviewed within 1 week.
• Most preliminary reviews are being reviewed within 1 week.

These stats are taken from the last queue report:

• 88 nominations in the queue awaiting review.
• 59 updates in the queue awaiting review.
• 57 preliminary review submissions in the queue awaiting review.

If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 21 Compatibility

The compatibility blog post for Firefox 21 is up, and the the compatibility bump for AMO add-ons was run last week. Firefox 21 was released yesterday, so all compatibility updates should be uploaded to AMO as soon as possible, if they haven’t been already.

As usual we recommend using the Aurora and Beta branches to test your add-ons ahead of time.

ESR Compatibility

There are a couple of compatibility issues that are related to the ESR and other business deployments that are worth mentioning:

• In Firefox 21, certain folders in the Firefox install directory where moved under browser/. You can read more about it on this bug. This affects installers that drop add-ons or other customizations in the install directory.
• We’re planning on changing the version number scheme for ESR releases. The idea is that, if we have ESR 24, ESR version 24.1 would be the security upgrade that corresponds to Firefox 25. This way it is easier to associate an ESR version with its mainline equivalent in security patches. For add-ons, this means that maxVersions should always be in the form 24.*, rather than 24.0.*. This is especially important for add-ons with binary components, which don’t have default compatibility.

General

• Split platform and app resources up so that they can be loaded individually. Adapting Firefox for Metro has lead to some things moving around, including a number of popular JS modules.
  • In Firefox 20 and below, resource:///modules/, resource://gre/modules/, and resource://app/modules/ point to the same location.
  • In Firefox 21 and above, resource://gre/modules/ and resource://app/modules/ point to different places and have different sets of modules in them. resource:///modules/ points to resource://app/modules/. Most of what you want is in /gre/, though. The easiest way to test is to open Firefox 21 or later and try loading the URLs you use to import the modules. If they still work, you’re good.
• Enable XBL Scopes. If you insert XBL bindings into content pages, calling functions to/from chrome can break under some circumstances and require additional code. You can read the details on the bug.
• Remove ability to set higher JS versions via language attribute. This means you can no longer explicitly set the JS version using the language attribute, even in XUL documents.
• Remove E4X from SpiderMonkey. E4X is no more.
• Give the -moz-orient property an ‘auto’ value, and make it the default.
• Change “-moz-user-select:none” to behave like “-moz-user-select:-moz-none”.
• Make parseInt(“042″) === 42.

Places

• Remove deprecated synchronous APIs from Places. Several synchronous functions have been removed. You can read the first comment in the bug for a list of the changes. This was also previously announced in the newsgroups.
• Remove nsINavHistoryFullVisitResultNode. It’s worth noting this also removed two constants that some add-ons use: nsINavHistoryResultNode.RESULT_TYPE_FULL_VISIT and nsINavHistoryResultNode.RESULT_TYPE_DYNAMIC_CONTAINER.
• Remove deprecated third argument from PlacesUIUtils.showBookmarkDialog.
• Drop livemarks support from FUEL.
• Remove onBeforeDeleteURI and onBeforeItemRemoved.
• Avoid replacing nodes in Places query results and remove nodeReplaced views notification. Removes nsINavHistoryResultObserver.nodeReplaced.

XPCOM

• nsIDownloadManagerUI uses obsolete download id. The optional download ID argument is now an nsIDownload object.
• ContentChild’s nsIConsoleListener should have threadsafe addref/release methods. This change caused bug 852220. In a nutshell, you shouldn’t expect nsIConsoleListener objects to be notified immediately when a message is logged. Removing the listener can result in lost messages.
• Remove expandEntityReferences from NodeIterator and TreeWalker.
• Remove nsSelectionIterator. Removes nsISelectionPrivate.getEnumerator.

New!

• Make language packs restartless by default. Yay!
• Expose secure PRNG in the DOM. window.crypto.getRandomValues will now get you cryptographically random values.

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

The automatic compatibility validation and upgrade for add-ons on AMO will happen very soon, so check your email if you have an add-on listed on AMO.

The Review Queues

• Most nominations for full review are taking less than 4 weeks to review.
• Most updates are being reviewed within 2 weeks.
• Most preliminary reviews are being reviewed within 2 weeks.

These stats are taken from the last queue report:

• 98 nominations in the queue awaiting review.
• 117 updates in the queue awaiting review.
• 105 preliminary review submissions in the queue awaiting review.

Our new reviewer incentives program has become a great motivator for our review team. If you’re an add-on developer, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 20 Compatibility

The compatibility blog post for Firefox 20 was already posted, and the the compatibility bump for AMO add-ons was run. Keep in mind that major changes happened for Private Browsing Mode and the Download UI in this release.

Firefox 21 Compatibility

The compatibility blog post for Firefox 21 should come out later this week, and we expect the compatibility bump to happen next week or the week after that.

The Review Queues

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

These stats are taken from the last queue report:

• 68 nominations in the queue awaiting review.
• 78 updates in the queue awaiting review.
• 89 preliminary review submissions in the queue awaiting review.

Our new reviewer incentives program has become a great motivator for our review team. If you’re an add-on developer, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 20 Compatibility

The compatibility blog post for Firefox 20 was already posted, and the the compatibility bump for AMO add-ons was run. Keep in mind that major changes happened for Private Browsing Mode and the Download UI in this release.

General

• When doing lazy tab restoration, set the <browser>s in question to display:none. This helps reduce memory consumption by loading as little as possible for tabs that were session-restored but haven’t been selected by the user yet. However, this also means that the content of those tabs will be inaccessible to add-ons. You can check for unloaded tabs using tab.getAttribute(“pending”) or tab.linkedBrowser.getAttribute(“pending”).
• Port the bookmarks export service to JavaScript. Eliminates nsIPlacesImportExportService and moves the migration function to BookmarkHTMLUtils.jsm.
• Implement the Downloads Panel. While the Download Manager still exists, this new UI significantly changes the way downloads appear initially.
• Turn javascript.options.xml.chrome off by default. This is the next step in completely removing E4X support in Firefox.
• Redirects visits are not notified anymore through history observers. This means history observers will get some new unexpected notifications.

Private Browsing

Private Browsing Mode is changing to support private and non-private windows opened at the same time. This means that many XPCOM interfaces and other functions are changing to support it.

• Remove the global private browsing service. This removes nsIPrivateBrowsingService for all practical services. The interface is still there for backward compatibility purposes, but it’s completely empty, along with its observer notifications: private-browsing, private-browsing-transition-complete, private-browsing-cancel-vote, private-browsing-change-granted.

There’s more information about the new private browsing in these docs: Supporting PBM, and Updating add-ons broken by PB changes.

XPCOM

• |non editable element|.QueryInterface(Components.interfaces.nsIDOMNSEditableElement) does not throw anymore. If you were using QueryInterface to check for editable elements, this won’t work in 20. While this was fixed in 21 and above, it’s recommended that you use instanceof instead.
• Refactor imgTools::DecodeImageData. This deprecates the decodeImageData function in favor of the new decodeImage function in the same interface.
• Convert XMLSerializer and DOMParser to WebIDL bindings. Removes nsIDOMParserJS. See nsIDOMParser for alternatives.
• Remove support for image-sniffing-services. This removes the image-sniffing-services XPCOM category.
• Move EventSource to Paris bindings. Removes nsIEventSource.

New!

• Context menu is not shown for form buttons and select elements.
• Add a RemoveAllDownloads API to nsIDownloadHistory.

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

The automatic compatibility validation and upgrade for add-ons on AMO will happen very soon, so check your email if you have an add-on listed on AMO.

The Review Queues

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

These stats are taken from the last queue report:

• 63 nominations in the queue awaiting review.
• 61 updates in the queue awaiting review.
• 60 preliminary review submissions in the queue awaiting review.

Our new reviewer incentives program has become a great motivator for our review team. If you’re an add-on developer, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 20 Compatibility

The compatibility blog post for Firefox 20 should be posted next week. The compatibility bump will be run shortly before release.

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.

Asynchronous Places [21]

A large number of Places APIs will be removed in Firefox 21, as Places continues to become fully asynchronous. The list of API changes and discussion is happening on this dev.extensions thread.

Per-window Private Browsing Mode [20]

Much has changed in the past couple of releases in preparation for per-window private browsing mode. In Firefox 20, most of what was left has been taken out, including nsIPrivateBrowsingService and some observer notifications.

Lazy Tab Restoration [20]

Firefox already implements this feature where old tabs are only loaded on demand after a Firefox restart. To further optimize this feature and save more memory,  the browser elements in these tabs will be set to display: none. This means that many assumptions about accessing such tabs are now broken, like the existence of a docShell, browser.contentWindow, etc. If your add-on looks into content of existing tabs, you should make sure it works with tabs that haven’t been loaded yet. This will ship in Firefox 20, currently on beta.

Java Click-to-Play

The continuous click-to-play blocks that we have been doing for Java may be breaking some add-ons that rely on Java code. We strongly recommend that you move away from Java and implement your add-on code either using JavaScript or external libraries and JS-ctypes. If you still rely on Java for your add-ons and have run into problems with click-to-play, this bug might help.

In case you missed it, give 2012 in Add-on Reviews a look. It’s a good overview of what the review team did last year and how it compares to previous years.

The Review Queues

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

These stats are taken from the last queue report:

• 72 nominations in the queue awaiting review.
• 101 updates in the queue awaiting review.
• 86 preliminary review submissions in the queue awaiting review.

Our new reviewer incentives program has become a great motivator for our review team. If you’re an add-on developer, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 19 Compatibility

The compatibility blog post for Firefox 19 is available here. The compatibility bump was run shortly before release.

The Firefox 20 blog post and bump should come in a couple of weeks.

General

• Remove XML Events. This is an obscure feature related to XForms, which was dropped long ago.
• Remove XTF. Another XForms-related feature.
• Rename mozallowfullscreen to allowfullscreen.

Private Browsing

Private Browsing Mode is changing to support private and non-private windows opened at the same time. This means that many XPCOM interfaces and other functions are changing to support it. The changes are mostly new parameters that tell the function which context it is being called from, so that it can work accordingly.

• ContentPrefService uses global Private Browsing state. All methods in this service now require the context to be passed to them.
• nsNavHistory uses global Private Browsing state. This changes some of the History component code to support the new per-window private browsing. There are no API changes in this patch, though.
• Add GUIDs to downloads. This adds a GUID to nsIDownloads, and APIs to handle downloads by GUID. The other APIs are still available, but will be gradually deprecated.
• nsStrictTransportSecurityService uses the global Private Browsing service.

There’s more information about the new private browsing in these docs: Supporting PBM, and Updating add-ons broken by PB changes.

XPCOM

• Improve signature of nsIConsoleService::GetMessageArray. This is an API improvement, but it affects many add-ons. The getMessageArray function used to require passing an object that would be modified to hold the return value. This was changed so the function now returns the array, so now you can do something like msgArray = consoleService.getMessageArray(…);
• Move DOMImplementation to Paris bindings. This changes nsIDOMDOMImplementation, making it non-scriptable.
• Remove the nsIDOMCanvasRenderingContext2D interface. This removes everything in nsIDOMCanvasRenderingContext2D except for the DRAWWINDOW_ constants.
• nsIUrlListManager.safeLookup not updated. The safeLookup function now takes an nsIPrincipal as an argument.
• Remove imgIRequest::loadImage’s aRequest argument.
• Change nsIChannel to support 64-bit content-length. This is just a return type change, so it should only affect binary add-ons, if any.

New!

• menuitems don’t inherit the “hidden” attribute from commands. Now they do
• Add an option ignoreExisting to OS.File.makeDir.

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

The automatic compatibility validation and upgrade for add-ons on AMO will happen very soon, so check your email if you have an add-on on AMO.