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.

• 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

• Total open bugs: 244
• Bugs created last week: 13
• Bugs fixed last week: 6
• Total SDK-based Addons on AMO: 385
• Open pull requests on Github: 25

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

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

• Remove the no-argument form of requestAnimationFrame. This function now takes one mandatory argument.
• Remove nsIDOMNSElement. This affects many SDK-based (Jetpack) add-ons using old versions of the SDK. We encourage you to update to the latest stable version as soon as possible.
• Remove the crazy navigator preservation behavior. If your add-on sets expando properties to the navigator object in web pages and relies on them keeping their state while navigating within the same domain, this concerns you.
• Remove ‘countryCode’ from nsIDOMGeoPositionAddress.idl. The non-standard countryCode property was removed.
• Kill dynamic containers. This is an obscure feature that was added to the bookmarks code but it was rarely used.
• Remove nsICharsetResolver.

Other important changes are noted in Firefox 11 for developers.

New stuff in 11!

• Support HTML parsing in XMLHttpRequest. The documentation page for this feature is being written at the moment, but it already has useful info.
• Sync add-ons. It seems Firefox Sync will be able to sync installed add-ons across devices. I doubt it will be able to sync all of your add-on configuration if your add-on writes custom files in the profile or elsewhere, though.
• Add a scriptable way to set a dock badge text. For Mac OS add-ons that want to write to the dock icon.

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.

The Review Queues

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

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

• 39 nominations in the queue awaiting review.
• 50 updates in the queue awaiting review.
• 49 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.

Firefox 10

The Firefox 10 compatibility post is here. The compatibility bump to Firefox 10 was run last week, so any add-ons with compatibility under 10.* should be tested and manually upgraded in the Developer Hub, if possible.

You can run the standalone compatibility tool if you want to test your add-on yourself or if it isn’t hosted on AMO.

The Add-ons Default to Compatible feature is progressing, and we expect to land on Firefox 10. Once this is in place, your compatibility worries will be minimized, and we’ll be taking a more active role in letting developers know if their add-ons are incompatible with a new version of Firefox. This feature will be a big win for both developers and Firefox users, so we’re very excited about it.

Firefox 11

A compatibility blog post for Firefox 11 is coming up. I apologize for the delay.

One side-effect of this change is that the resource urls for files in the data folder of an add-on have changed. If you have created an add-on and for some reason hard-coded a resource url into your code, you will need to change your code in order for your add-on to work when packaged with SDK version 1.4.

While the release notes go into this issue in detail, I would like to highlight here the two main examples we are seeing in the wild of hard coded resource uris, with strategies for working around each.

1. Hard coded resource uris in main.js

Addon authors occasionally reference html and javascript files in the addon’s data directory directly via a hard-coded string:

var myPanel = require("panel").Panel({
  contentURL: "resource://jid1-294x0ji6mesjag-at-jetpack-example-data/my-file.html",
  contentScriptFile: "resource://jid1-294x0ji6mesjag-at-jetpack-example-data/my-script.js"
});

You should always use the method self.data.url instead:

var data = require("self").data;
var myPanel = require("panel").Panel({
  contentURL: data.url("my-file.html"),
  contentScriptFile: data.url("my-script.js")
});

2. Hard coded resource uris in html or css files inside the data directory.

Referencing a css or image file from an html or css file in the addon’s data directory does not require the entire resource uri path because these resources can be referenced with relative paths. Instead of doing this:

<html>
  <body>
    <img src="resource://jid1-294x0ji6mesjag-at-jetpack-example-data/my-file.png"/>
  </body>
</html>

…all you need to do is this:

<html>
  <body>
    <img src="my-file.png"/>
  </body>
</html>

If you have created an SDK-based addon and have included some hard-coded resource uris in your code, you will only need to make changes to address this issue if you re-package your addon with 1.4. As we are not re-packing addons on AMO automatically for this release, there is no immediate need to update your code.

It is possible 6 weeks from now that we will re-pack all addons to use SDK 1.5, and at this point any remaining addons using hard-coded resource uris will stop working. To mitigate this we are working with the AMO team to identify all affected addons and contact addon authors directly to encourage them to update and use the best practices I demonstrated above.

If you are a Firefox developer, support professional, or contributor, your help is critical—if you think there might be a compatibility issue in any of the release channels, please file a bug here so we can take action right away if needed.

In general, it would be super helpful for everyone to install the Add-on Compatibility Reporter and let us know through the reporter if your add-ons are working properly.

Your help is greatly appreciated!

The Review Queues

• Nominations for full review at the moment are being processed slower than usual. Most nominations are taking less than 4 weeks to review.
• Most updates are being reviewed within one week.
• Most preliminary reviews are being reviewed within 2 weeks.

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

• 74 new nominations that week. 153 nominations in the queue awaiting review.
• 115 new updates that week. 120 updates in the queue awaiting review.
• 97 new preliminary review submissions that week. 160 preliminary submissions in the queue awaiting review.

Waiting times are rapidly dropping and will continue to drop in the following weeks thanks to our New Years Challenge. There’s still plenty of time to participate and win great prizes, including tablets and a laptop.

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

Firefox 10

The Firefox 10 compatibility post is here. The compatibility bump to Firefox 10 was run last week, so any add-ons with compatibility under 10.* should be tested and manually upgraded in the Developer Hub, if possible.

You can run the standalone compatibility tool if you want to test your add-on yourself or if it isn’t hosted on AMO.

The Add-ons Default to Compatible feature is progressing, and we expect to land on Firefox 10 or 11. Once this is in place, your compatibility worries will be minimized, and we’ll be taking a more active role in letting developers know if their add-ons are incompatible with a new version of Firefox. This feature will be a big win for both developers and Firefox users, so we’re very excited about it.

Firefox 11

A compatibility blog post for Firefox 11 is coming up.

You can read more about the plan, including how we determine eligibility for automatic compatibility here. For additional background reading, check out this blog post.

Once you have Aurora installed, all add-ons that are compatible with Firefox 4 or later can be installed without extra steps. Firefox will install them even if they are declared incompatible in the manifest file.

If you don’t already have Aurora installed, you can get it here. With Aurora, you’ll see our newest features before they go beta, and have a chance to send us feedback before the final release.

Please send us feedback or file bugs on the new default to compatible feature here. We look forward to hearing from you!

AMO Outage

We had a significant outage on our site (and others) earlier this week, which affected some add-on operations such as compatibility checks. AMO is back to normal now and we’re looking into ways of avoiding this from happening again.

The Review Queues

• Nominations for full review at the moment are being processed slower than usual. Most nominations are taking less than 5 weeks to review.
• Most updates are being reviewed within 10 days.
• Most preliminary reviews are being reviewed within 3 weeks.

These stats are taken from the last queue report:

• 67 new nominations that week. 224 nominations in the queue awaiting review.
• 101 new updates that week. 135 updates in the queue awaiting review.
• 78 new preliminary review submissions that week. 115 preliminary submissions in the queue awaiting review.

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

Firefox 10

The Firefox 10 compatibility post is here. The compatibility bump to Firefox 10 was run last week, so any add-ons with compatibility under 10.* should be tested and manually upgraded in the Developer Hub, if possible.

You can run the standalone compatibility tool if you want to test your add-on yourself or if it isn’t hosted on AMO.

The Add-ons Default to Compatible feature is progressing, and we expect to land for Firefox 10 or 11. Once this is in place, your compatibility worries will be minimized, and we’ll be taking a more active role in letting developers know if their add-ons are incompatible with a new version of Firefox. This feature will be a big win for both developers and Firefox users, so we’re very excited about it.

As usual, you should check Firefox 10 for Developers for additional information.

DOM Changes

• Remove isSameNode. This is the change that has the greatest impact by far, since it is used in many add-ons and web sites. To compare nodes you can use the === operator instead.
• Remove isElementContentWhitespace.
• Remove replaceWholeText().
• Remove Document.xmlEncoding.
• Remove Document.xmlStandalone.
• Remove Document.xmlVersion.

XPCOM Changes

• Remove support for browser.startup.page == 2. This setting wasn’t in use, but a consequence of this change is that the lastPageVisited property in nsIBrowserHistory was removed.
• Remove nsIDOMNSHTMLFrameElement. Use nsIDOMHTMLFrameElement instead.
• Remove nsIDOMNSHTMLElement. Use nsIDOMHTMLElement instead.
• Switch from PRBool to bool. The PRBool type was cleaned up all around in favor of bool.
• Remove nsIDocumentViewer.
•  Implement IndexedDB setVersion API changes. This changes several DB interfaces, but they are meant for internal usage.
• Remove nsNavHistory nsICharsetResolver implementation.

Other Changes

• fastload XBL methods and properties. If you use XBL, make sure you test it thoroughly. If you run into bugs that can’t be reproduced in Firefox 9, please let us know!
• Different regular expression result since Firefox 7. A small RegExp fix, but it can change the result of certain expressions.
• Mandatory ASLR on Windows. Binary components should work with ASLR, otherwise there will be a performance penalty when loading them in Firefox. We’re also considering adding detection for non-NX and non-ASLR binaries on AMO, possibly rejecting them.

New stuff!

• Support taskbar icon overlay in Windows 7. This allows extensions to add icons to the taskbar icon on Windows 7. There’s a sample linked in the bug in case you’re interested.
• Load/unload chrome.manifest files for bootstrapped addons dynamically. Chrome in bootstrapped add-ons, whoo! Well, it has been possible since before, but now it’s real easy.
• Add support for mouseenter and mouseleave events.

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, I’d like to know.

The compatibility bump to Firefox 10 will happen very soon. If you want your add-on to qualify for this, it should be compatible with 9.*. Versions awaiting review also qualify.