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.

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.

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.

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.

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.

The Review Queues

• Nominations for full review at the moment are being processed slower than usual. Most nominations are taking about 6 weeks to review.
• Most updates are being reviewed within 2 weeks.
• Most preliminary reviews are being reviewed within 3 weeks.

These stats are taken from the last queue report:

• 82 new nominations that week. 247 nominations in the queue awaiting review.
• 116 new updates that week. 149 updates in the queue awaiting review.
• 66 new preliminary review submissions that week. 104 preliminary submissions in the queue awaiting review.

If you’re interested in joining the AMO Editors team and help us review add-ons, please read the page on How to Apply.

Firefox 8

There’s a bug that affects themes in Firefox 8, in Mac OS X Lion. Please read this blog post if you’re a theme developer.

Firefox 9

The Firefox 9 compatibility post is here. The compatibility bump to Firefox 9 was run weeks ago, so any add-ons with compatibility under 9.* 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.

We strongly recommend that you aim to make your add-on compatible with the Firefox version in the Aurora channel. Making your add-on compatible with Aurora qualifies it for our automatic compatibility upgrades, saving you lots of time. If you need more information about this, don’t hesitate to ask.

Firefox 10

Compatibility update coming soon!

The Review Queues

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

These stats are taken from the last queue report:

• 67 new nominations that week. 243 nominations in the queue awaiting review.
• 111 new updates that week. 126 updates in the queue awaiting review.
• 44 new preliminary review submissions that week. 267 preliminary submissions in the queue awaiting review.

If you compare these numbers to the last report, you’ll see we’re improving on most fronts. We continue to ramp up our efforts, and we’re in the process of introducing new editors from the Jetpack team, who should be able to help reviewing SDK-based add-ons.

If you’re interested in joining the AMO Editors team and help us review add-ons, please read the page on How to Apply.

Firefox 8

The Firefox 8 compatibility post is here.

You should note that there are a couple of possible reversals coming into Firefox 8 that affect add-on developers, mostly in good ways:

• Bring back ISO8601DateUtils.jsm. Since the Date object isn’t exactly equivalent to this module and some significant add-on breakage was expected from its removal, it will be brought back for the time being. You should still change your add-ons so that it isn’t used anymore, but it’ll be at least one more release before it is completely removed.
• Back out bug 455694 (tab drag/detach animations). There is no final decision on this yet. The backout patch has been checked in for testing and you should track this bug if it affects your add-on.
• 3rd party add-on check doesn’t disable add-ons that were installed into the profile or application folder. The third party add-on check is being extended to include add-ons installed directly in the application folder or in the profile. This doesn’t affect any add-ons installed through the regular add-on installation process, or if they are installed manually from a local file. This should only affect add-ons that are automatically installed from an external package and copied into these other locations. It can affect add-on developers who have automatic installation processes to test their new code. You should read this comment for information on how to bypass this check and avoid the dialog at startup.

Firefox 9

The Firefox 9 compatibility post is here. The compatibility bump to Firefox 9 was run last week, so any add-ons with compatibility under 9.* 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.

We strongly recommend that you aim to make your add-on compatible with the Firefox version in the Aurora channel, Firefox 9 at this moment. Making your add-on compatible with Aurora qualifies it for our automatic compatibility upgrades, saving you lots of time. If you need more information about this, don’t hesitate to ask.

Without further ado, here they are.

Possible Add-on Compatibility Changes

• Semicolon in URI path handled incorrectly. While this removes a fairly obscure feature of URIs, it changes nsIURL and other related components, which many add-ons rely on. nsIURL.param was removed, and one argument was removed from nsIURLParser.parsePath.
• Cleanup/remove geo.wifi.* preferences. The preferences geo.wifi.uri and geo.wifi.protocol were removed, and the URI is now hardcoded in NetworkGeolocationProvider.js. I asked in the bug what the reason behind this change is, but I haven’t received any replies yet. Update: a comment in the bug has clarified that the preference is still being honored. The change is that this preference won’t have a default value and therefore won’t appear in about:config. It is still possible to set its value using the pref service, or creating a new string preference in about:config with the right name. Add-ons reading this preference still need to update their code if they aren’t expecting any exceptions when reading it without setting it first.
• Remove Navigator.taintEnabled(). This method doesn’t do anything useful, but since it is Netscape-specific, it has been used in browser detection scripts, and some of those made their way into add-ons. Calling this method should throw an exception starting with Firefox 9.
• Move nodePrincipal and baseURIObject onto XrayWrapper and remove from nsDOMClassInfo. This one should only affect add-ons that try to access the baseURIObject, nodePrincipal, and documentURIObject properties on a DOM Node from an unprivileged script that has requested XPConnect privileges using enablePrivilege. Since we have been discouraging enablePrivilege usage on AMO for quite a while, I don’t expect any of the add-ons we host to be affected.
• Improve responsiveness of history removals. This removes a couple of deprecated methods from nsIBrowserHistory: registerOpenPage and unregisterOpenPage.
• Nuke nsIGlobalHistory3. Removes nsIGlobalHistory3, which shouldn’t have much use for add-ons anyway.
• Remember spell check setting per site. Removed nsIEditorSpellCheck.saveDefaultDictionary.

The list of compatibility validation bugs is here, if you’re interested. They should be fixed this week and pushed to the site on Thursday. I intend to run the bulk compatibility upgrade on Friday, but it could be delayed until next week if anything else comes up.

Possible Binary Compatibility Changes

These are some changes that I thought were notable and could interest binary XPCOM add-on developers. They are, for the most part, changes to IDL interfaces that won’t break JS callers, like new methods and attributes.

While you will always need to recompile your components, this list might save you some time if you run into compilation issues.

• Implement document.scripts. Adds nsIDOMHTMLDocument.scripts.
• Provide a way to play the “ding” system sound used to indicate typing too many characters in a text field on Windows. Adds nsISound.EVENT_EDITOR_MAX_LEN.
• Add support for fave icons on jump list uri entries. Adds nsIJumpListShortcut.iconImageUri.

Other Notable Changes

• Crash nsTHashtable with HTTPS everywhere extension. There’s a long discussion in this bug that should be interesting to those whose extensions have to filter or redirect web requests in sophisticated ways. You should be aware that URIs are assumed immutable in some parts of the Mozilla code, even though they technically aren’t. Changing URI instances mid-flight is the reason behind this crash. A fix was issued and will also be included in Firefox 8.
• Add contentDisposition{Filename} properties to nsIChannel. This folds some attributes related to content disposition from specialized channels into the more generic nsIChannel. Since other channel classes inherit from nsIChannel, the change should not cause problems with existing code.
• Add-ons are failing to install. If you use the same profile to test Firefox 9 and earlier versions, there’s a chance that add-on installation will fail after testing on 9 and going back to an earlier version. Fixes already exist for Firefox 8 and Firefox 9, and they should become available soon.
• mouseenter and mouseleave events are not supported. This implements those 2 events. Update: This is being reverted.
• Checkbox inside a prefwindow doesn’t affect the preference when it has a command.

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

Remember, the compatibility bump to Firefox 9 will happen later this week. If you want your add-on to qualify for this, it should be compatible with 8.*. We have moved as many add-ons as we could to 8.*, but it is possible that your add-on is compatible and hasn’t been marked as compatible by our tools. If this is your case, you still have a few days to upgrade your compatibility on AMO or upload a new version.