The problem is that the window load event handler that many add-ons depend on isn’t fired under some circumstances. So far it appears that this only happens when a popup window is opened, and only in cases where the domain in the new window is different from the one that opened the window. Since most add-on scripts rely on the load handler being called, many of them will not work in the newly opened popup window. There’s more information about this in bug 799348.

At the moment we consider the impact of this bug to be fairly minor, so it won’t be fixed until Firefox 17 unless there are sufficient reasons that merit the creation of a 16.0.1 update. If your add-on is affected by it, please let us know how in the comments.

override chrome://browser/skin/Toolbar.png chrome://browser/skin/lion/Toolbar.png os=Darwin osversion>=10

This breaks themes that try to reference Toolbar.png, since Firefox will look in the different location (in the lion subdirectory). Possible workarounds include using a different file name for the toolbar sprite and change all references in the theme, or adding a duplicate or similar file in the location Firefox expects to find it.

We haven’t decided on any solutions for this problem, but you can follow this bug if you’re interested in the outcome.

And since we’re talking themes, theme developers should read Wladimir’s post about making themes more like overlays and less like overrides. It’s a very interesting topic that was brought up at MozCamp and that I’d like to discuss it more in the future. Having feedback from theme developers is very important to give this idea some traction.

Here are the add-on compatibility-breaking bugs I identified that have been fixed in Firefox 8, currently in the Aurora track:

• Remove ISO8601DateUtils.jsm. The Date object now supports the capabilities this module provided, so there’s no need for it anymore.
• Remove nsIDOMWindowInternal. This change affected many add-ons, so it was reverted. However, the interface is deprecated and may be removed in the future. We added a compatibility warning explaining that nsIDOMWindow should be used instead.
• document.getSelection() should return the same as getSelection(), not stringification. This changed the return value of document.getSelection so that it matched window.getSelection. Instead of a string, it returns an object now.
• Merge nsISelection* interfaces. A couple of relatively obscure interfaces were merged into nsISelection. The latter should be used instead.
• The implementation of the File API introduced one global called File, which could conflict with objects in your scripts. We learned about this change after the bump, but it would have been very difficult to create a validator check for this anyway. It would’ve been too noisy. If you have globals named File, you should rename them.
• In the same vein, a global named ChromeWorker was introduced. There’s no validation for it, but no add-ons are affected as far as we know. This constructor was introduced instead of the XPCOM interfaces that existed before it, like nsIWorkerFactory. Most of this work is detailed in this bug. We learned about this change after the fact as well, but we don’t expect many add-ons to be affected by it. Please let us know if this affects you.
• Remove SSL 2.0 support. This doesn’t affect any current add-ons, so we didn’t add validation for it. It just means some very old code was removed, as well as these preferences: security.enable_ssl2 (false by default) and security.ssl2.*.

Here are a few other changes that probably interest you but don’t break compatibility as far as we can tell:

• Users should have exclusive control over selecting their add-ons. Third-party add-ons that weren’t installed by the user voluntarily will be disabled when users upgrade to Firefox 8. There will be a dialog where users will be able to choose which add-ons to keep and which add-ons to remove. This somewhat controversial decision has been discussed before.
• Replace binary xpidl xpt output with a python version hooked up to xpidl.py. This is a big change if you compile IDL files for your add-ons. The binary xpidl tool has been replaced with a Python script.
• Allow caching JS loaded with loadSubScript. This will improve the performance of add-ons that dynamically load many scripts. It will be particularly useful for Jetpack-based add-ons, which load a large amount of scripts.
• about:config should support URL query for specific prefs. This is just a nice little shortcut for editing preferences in about:config.
• Save chosen download file name and other metadata in Places history. This is just an addition to Places that might be useful for extension developers.

As always, there’s more detailed information in Firefox 8 for Developers. If there’s anything missing here or in the MDC page, or if you had any problems with the latest compatibility bump, please let us know in the comments.

We’re also streamlining the breaking change detection process, and I posted in the newsgroups about this: Keeping add-ons compatible in the rapid release process. Please have a look and let us know what you think.

The bug that introduced this change has a good explanation by Jim Mathies on what changed and how to fix it, which I will just quote verbatim since I couldn’t explain it any better:

In past versions Firefox calculated the location of glass boundaries (the point at which transparent window margins end) automatically. In version 6.0 this was replaced with an opt-out style where XUL elements are marked explicitly as opaque via css. Currently various UI elements have this new style including the main content area of the browser, downloads window content, and extension’s about dialog.

The css property we use to identify opaque regions is through a new value for the moz-appearance style:

-moz-appearance: -moz-win-exclude-glass;

Themes which modify browser css must mimic what the default theme is doing as far as content is concerned. If content is not excluded, various anomalies can show up, most notably in windowed plugins which display improperly when placed on transparent window surfaces.

For reference:
http://mxr.mozilla.org/mozilla-central/search?string=moz-win-exclude-glass

If you’re a theme developer, please update your themes accordingly. This should only affect your theme if you use -moz-win-glass or -moz-win-borderless-glass. The AMO Editor team is aware of this situation and updates due to this bug are being given a high priority.

If you are a theme user and this problem affects you, we recommend that you check for updates (many themes have fixed versions available already), and let the theme developer know about this blog post. Disabling or uninstalling the theme should fix the faulty behavior, in case you need an immediate fix.

Our analysis of the bug fixes for Firefox 7 has produced the following list of notable changes for add-on developers. They are mostly XPCOM interface removals, some of them currently in use by add-ons listed on AMO. Please have a look and update your add-on code accordingly:

• The encode and decode methods in nsIJSON have been removed. Bug 645922. This fix affects a very large portion of add-ons, so there’s an effort aiming to revert it. Either way, we strongly recommend you to use the global JSON object and the parse and stringify functions instead of the XPCOM component.
• (Updated) The nsINavHistoryObserver and nsINavBoorkmarkObserver interfaces have changed to better accommodate Firefox Sync. Bug 633266. Several of its methods have a new parameter (a GUID). Since add-ons are normally in the observer position, this just means you get more data, so no change is necessary. Binary consumers will need to update the function signatures, though.
• (Updated) A number of methods have been removed from the nsIDOMFile interface, notably getDataAsURL and getAsBinary. Bug 661876. Equivalent functions are available in other objects, like FileReader.
• A few other interfaces were removed: nsIDOM3Node (bug 659053), nsIDOM3TypeInfo (bug 660539), schemaTypeInfo (bug 660539), nsIDOMNSDocument (bug 658906), and nsIDOMDocumentStyle (bug 658904).

More details can be found in Firefox 7 for Developers, as well as some new features that really exciting to have:

• It is now possible to unload JS modules, making them a more viable option for restartless add-ons. Bug 481603.
• Inline preferences. You can now display your preferences panel inside the Add-ons Manager, instead of using a separate window. While there are limitations to what you can do with this, it should work fine for a large subset of add-ons. Plus, it also works for restartless add-ons, which is a big win.

If there are any other compatibility troubles you have run into while testing on Firefox 7 that hasn’t been mentioned here, please leave a comment below.

Firefox 8

It’s still early to worry about Firefox 8, but there are a couple of big changes coming your way that I thought I should mention as soon as possible:

• The nsIDOMWindowInternal interface will be removed. Bug 670235. Judging by the patch, you should be doing QI to nsIDOMWindow instead.
• There is work being done to implement an incremental GC for the JS engine. This could potentially affect add-ons with binary components that use the JSAPI to create a custom JSClass and
  objects of that class, and the objects of the custom class have a custom GC trace function. It sounds fairly specific to actually be common, but I just want to throw this out there in case anybody is affected by it. You can contact me if you need more information about this.

Firefox 8 for developers is already available and should be growing in length in the following weeks.

The new rapid release schedule for Firefox is in effect, and you can already get preview versions of Firefox 5 and Firefox 6 in the Beta and Aurora channels, respectively. Firefox 5 will most likely be released in a couple of weeks, and Firefox 6 should follow 6 weeks later.

Because of the fast-paced schedule, these new releases are less problematic for add-on developers given that they include very few compatibility-breaking changes. This post covers all known add-on compatibility issues with Firefox 5 and 6. If you have run into other issues and don’t see them mentioned here or documented anywhere else, please let us know.

We have already done an automatic compatibility upgrade to Firefox 5 for all add-ons that qualified for it, and we will do a similar upgrade for 6 sometime this week, maybe later today.

How do we select which add-ons to upgrade? They need to be compatible with the previous Firefox version, they must not have binary components (since they usually need to be rebuilt) and they need to pass special compatibility tests that we create based on the known breaking changes, which are listed below.

Firefox 5

• The value of navigator.language no longer reflects the language of the Firefox UI (Bug 55366). To obtain the UI language you can use the general.useragent.locale preference instead.
• The default behavior of setTimeout and setInterval when no wait time is set has changed (Bug 610077). If you set the timer to a very low value the actual wait time would be rounded to 10ms before. Now, that minimum has changed, and it depends on where the code is running.
• A number of words are now reserved in JavaScript, even when not in strict mode (Bug 637204). The newly reserved words are class, enum, export, extends, import and super. You shouldn’t use these words anywhere in your code, even as object property names. Some add-ons that are affected by this might have been automatically upgraded to Firefox 5 compatibility, so please check your code and look for any errors during execution in Firefox 5.
• Instantiating nsICertOverrideService (and perhaps others) at startup can make Firefox unusable (Bug 650858). We caught this one recently, and we’re still gauging its impact. The bug is only manifested if you try to instantiate a service before the load event. This is easy to avoid:

WRONG

var comp = Components.classes[...].getService(...);
var MyObject = {
  init: function() {},
  ...
}
window.addEventListener("load", function() { MyObject.init(); }, false);

WRONG

var MyObject = {
  comp : Components.classes[...].getService(...),
  init: function() {},
  ...
}
window.addEventListener("load", function() { MyObject.init(); }, false);

RIGHT

var MyObject = {
  comp : null,
  init: function() {
    this.comp = Components.classes[...].getService(...);
  },
  ...
}
window.addEventListener("load", function() { MyObject.init(); }, false);

Just don’t instantiate any components before the load event. Better yet, follow our performance best practices and don’t instantiate anything until it’s needed.

• Mac OS SDK builds for the beta are missing (Bug 653971). This affects you if you build binary components for Mac OS. There are several bugs involved in this, but they are being tracked in this bug. It should be fixed within a few days.
• XPCOM binary component registration no longer ignores Module::kVersion (Bug 656331).
• More documented changes in Firefox 5 for developers.

Firefox 6

• The app.update.timer preference was replaced by the app.update.timerMinimumDelay preference (Bug 614181).
• A few interfaces (rarely) used in add-ons have been removed: IWeaveCrypto (Bug 651596), nsIDOMDocumentTraversal (Bug 655514) and nsIDOMDocumentRange (Bug 655513).
• window.top is now read-only (Bug 654137). This affects your add-on if you use an undeclared variable called top in a chrome script.
• javascript: and data: URLs entered into the location bar no longer inherit the principal of the currently-loaded page (Bug 656433). Maybe this won’t affect any add-ons, but there are many workarounds and odd pieces of code in the wild, so it’s better that you double check if you run any code using these types of URL.
• New Web Developer Sub-menu in the Tools menu (Bug 653221). Because of all the new developer tools being included in Firefox, it was determined that it was best to group them in a sub-menu. This means that many overlays – those that rely on these menuitems being direct children of the Tools menu – will be affected. Your overlays will continue to work, but your items will most likely end up at the bottom of the menu instead of where you want them.
• Reordering of the History menu (Bug 625322) and the Bookmarks menu (Bug 625325). This may affect your add-on if you overlay or work on those menus.
• The clearUserPref method no longer throws if the pref doesn’t have a user value (Bug 487059).
• Implement Site-Specific Privacy Preferences (Bug 573176). This should only affect add-ons that rely on certain preferences (privacy, remember passwords, and others) being in the main preferences window.
• More documented changed in Firefox 6 for developers.

Once again, if there’s anything missing in these lists, please let us know. Thank you!

A couple of months ago I wrote an overview of toolbar buttons in Firefox 4, including all the CSS and image work necessary for your add-ons to work on all 3 platforms. It was met with many questions, the gist of them being why is this so convoluted when it could be really simple? So, bugs were filed and revisited, and many problems were finally solved.

Firefox 4 beta 12 will contain fixes for bug 626382 and bug 616472, both of which bring the necessary icon and styling work down to almost the bare minimum. You can test these changes on the current nightlies

First of all, if you followed the recommendations in the previous article, no changes should be required. I tested the add-on I created for that post on the latest beta on all platforms and it worked just the same. So, if you already did the compatibility work for Firefox 4 testing in earlier betas, you should be good. Now let’s get to the new, simpler way of doing this.

Assuming you want to support all 3 major platforms and your add-on adds a toolbar button, the minimum you need is a 16×16 px icon and a 24×24 px icon. The 24×24 px icon is normally only used on the default Linux theme (I tested on Ubuntu) on Large Icons mode, which is the default value for the main toolbar. For all other platforms and modes, the 16x16px icon is used, with varying margins around it on Windows. In terms of CSS, all you need is this:

#icondemo-toolbar-button {
 list-style-image: url("chrome://icondemo/skin/toolbar-large.png");
}

toolbar[iconsize="small"] #icondemo-toolbar-button {
 list-style-image: url("chrome://icondemo/skin/toolbar.png");
}

Nothing else is needed.

Now, if you want to take this one step further and be a better Mac OS X citizen, your icon will look much better if it’s monochrome. For this, I recommend using chrome manifest flags to either have completely different skins altogether, or just override the main skin with the Mac OS skin when necessary. The sample add-on in the previous article uses the former, the sample add-on in this one uses the latter.

Here’s a link to the demo add-on I adjusted for the new system. It’s simpler and smaller because of one icon and some CSS files that weren’t needed anymore.

If you’re a theme author or you want to understand the details of the new system, perhaps if you need specially-sized icons for your add-on, you should read this comment that explains the changes very well. Alfred Kayser also maintains this Mozillazine thread up to date with everything that concerns theme authors. Thank you, Alfred!

Also, special thanks to Dao and Paolo for all the hard work they put into resolving these bugs!

• These posts written every 2 weeks explain the current state of add-on reviews and other information relevant to add-on developers.
• A few weeks ago, a new version of the Developer Tools was pushed live at AMO. It includes a new review process among a ton of other changes. More information here.
• Nominations at the moment are being processed very slowly. The new review system required hundreds of add-on developers to renominate their add-ons, which has placed a large workload on the editor team. Nominations have been delayed at least a couple of weeks.
• Most updates are being reviewed within 7 days.
• Most preliminary reviews are being reviewed within 15 days.

The Review Queues

• These stats are taken from the last queue report. Preliminary queue stats are still pending.
• 58 new nominations that week. 194 nominations in the queue awaiting review.
• 74 new updates that week. 62 updates in the queue awaiting review.
• 985 reviews have been performed by AMO Editors this month.

Firefox 4 Compatibility

Firefox 4 will be released very soon, beta 10 is currently available for download and AMO already supports 4.0.* as a valid maxVersion. Most of the necessary documentation to upgrade your add-on for Firefox 4 is readily available:

• Firefox 4 for developers at MDC.
• Making your add-on compatible with Firefox 4.
• Firefox 4 Compatibility discussion in the Add-ons Forum. This is the best place to post any feedback and bugs related to Firefox 4 and add-on development.

Beta 7 was the first release after the codebase went through feature freeze. This means that no major changes are going to be performed, and add-ons that work correctly on current betas are likely to work in the same way until the final release. Here are some pending issues of Firefox 4 compatibility that haven’t been addressed in other blog posts:

• Since toolbar buttons are very important for developers and button sizes changed for Firefox 4, I wrote this analysis of toolbar buttons and icons in Firefox 4. One problem was brought up in the comments, which triggered the creation of bug 616472. The bug and other related ones have been fixed on the latest betas. I’ll post an update on this topic very soon, so stay put.
• The Add-on Bar is supposed to appear automatically when a button or other items are added to it. Bug 616419 was filed for this. It doesn’t look like it will be fixed soon, but an alternate solution is proposed in the comments.

Notes for Developers

• Add-on Performance at XUL School. This article is highly recommended to all developers. It explains a few methods to improve add-on performance, including how to easily measure startup times.
• The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process. It’s currently being edited to adjust it to the upcoming review system.
• Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla

• These posts written every 2 weeks explain the current state of add-on reviews and other information relevant to add-on developers.
• A few weeks ago, a new version of the Developer Tools was pushed live at AMO. It includes a new review process among a ton of other changes. More information here.
• Nominations at the moment are being processed very slowly. The new review system required hundreds of add-on developers to renominate their add-ons, which has placed a large workload on the editor team. Updates and preliminary reviews are under control, but nominations have been delayed at least a couple of weeks.
• Most updates are being reviewed within 5 days.
• Most preliminary reviews are being reviewed within 10 days.

The Review Queues

• These stats are taken from the last queue report. Preliminary queue stats are still pending.
• 97 new nominations that week. 534 nominations in the queue awaiting review (yeah, that’s not a typo).
• 81 new updates that week. 109 updates in the queue awaiting review.
• 2416 reviews were performed by AMO Editors in the month of January. That’s a new review record for us

Firefox 4 Compatibility

Firefox 4 will be released very soon, beta 10 is currently available for download and AMO already supports 4.0.* as a valid maxVersion. Most of the necessary documentation to upgrade your add-on for Firefox 4 is readily available:

• Firefox 4 for developers at MDC.
• Making your add-on compatible with Firefox 4.
• Firefox 4 Compatibility discussion in the Add-ons Forum. This is the best place to post any feedback and bugs related to Firefox 4 and add-on development.

Beta 7 was the first release after the codebase went through feature freeze. This means that no major changes are going to be performed, and add-ons that work correctly on current betas are likely to work in the same way until the final release. Here are some pending issues of Firefox 4 compatibility that haven’t been addressed in other blog posts:

• Since toolbar buttons are very important for developers and button sizes changed for Firefox 4, I wrote this analysis of toolbar buttons and icons in Firefox 4. One problem was brought up in the comments, which triggered the creation of bug 616472. The bug and its dependencies are progressing, and hopefully all the fixes will be included on the next beta. Once they make it to a beta or release candidate, I’ll post an update to the toolbar button article.
• I posted an explanation about the threading and worker changes in Firefox 4. If your add-on used the Thread Manager and doesn’t work in Firefox 4, that article is meant for you.
• The Add-on Bar is supposed to appear automatically when a button or other items are added to it. Bug 616419 was filed for this. It doesn’t look like it will be fixed soon, but an alternate solution is proposed in the comments.

Notes for Developers

• Add-on Performance at XUL School. This article is highly recommended to all developers. It explains a few methods to improve add-on performance, including how to easily measure startup times.
• The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process. It’s currently being edited to adjust it to the upcoming review system.
• Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla

• These posts written every 2 weeks explain the current state of add-on reviews and other information relevant to add-on developers.
• Last week a new version of the Developer Tools was pushed live at AMO. They include a new review process among a ton of other changes. More information here.
• Most nominations are being reviewed within 10 days.
• Most updates are being reviewed within 5 days.
• Most preliminary reviews are being reviewed within 5 days.

The Review Queues

• These stats are taken from the last queue report. It doesn’t include the new preliminary review queue because that was pushed live the day before.
• 48 new nominations that week. 64 nominations in the queue awaiting review.
• 86 new updates that week. 55 updates in the queue awaiting review.
• 791 reviews have been performed by AMO Editors this month.

Firefox 4 Compatibility

Firefox 4 will be released very soon, beta 9 is currently available for download, and AMO already supports 4.0.* as a valid maxVersion. Most of the necessary documentation to upgrade your add-on for Firefox 4 is readily available:

• Firefox 4 for developers at MDC.
• Making your add-on compatible with Firefox 4.
• Firefox 4 Compatibility discussion in the Add-ons Forum. This is the best place to post any feedback and bugs related to Firefox 4 and add-on development.

Beta 7 was the first release after the codebase went through feature freeze. This means that no major changes are going to be performed, and add-ons that work correctly on current betas are likely to work in the same way until the final release. Here are some pending issues of Firefox 4 compatibility that haven’t been addressed in other blog posts:

• I just posted an explanation about the threading and worker changes in Firefox 4. If your add-on used the Thread Manager and doesn’t work in Firefox 4, that article is meant for you.
• Since toolbar buttons are very important for developers and button sizes changed for Firefox 4, I wrote this analysis of toolbar buttons and icons in Firefox 4. One problem was brought up in the comments, which triggered the creation of bug 616472. It has already been fixed at least for Mac, which now accepts 16×16 px icons, and there’s a proposal to provide an automatic filter that converts icons to monochrome, allowing authors to use the same graphic without the colors breaking the general look of Firefox on Mac. Other improvements are being discussed in the bug at the moment and would appear on the next beta if implemented.
• The Add-on Bar is supposed to appear automatically when a button or other items are added to it. Bug 616419 was filed for this. It doesn’t look like it will be fixed soon, but an alternate solution is proposed in the comments.

Notes for Developers

• Add-on Performance at XUL School. This article is highly recommended to all developers. It explains a few methods to improve add-on performance, including how to easily measure startup times.
• The AMO Editor Guide. This new page in the wiki is a comprehensive guide to the work performed by AMO Editors. It will serve as an introductory guide for new editors, and is a step forward in being as transparent as possible with our review process. It’s currently being edited to adjust it to the upcoming review system.
• Useful Information for Add-on Authors. How to improve review times for your add-on, information about the review process, etc.

Jorge Villalobos

Add-ons Developer Relations Lead, Mozilla