Firefox 32 will be released on September 2nd. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 32 for Developers, so you should read that too.
- Combined navigation items in the context menu. If you right-click on a page using Firefox 32 and above, you’ll see a row of icons at the top used for navigation and bookmarking. If your add-on depends on the node structure of the context menu, this change could affect it.
- Avoid loading the xul.css UA style sheet when possible. This could break your extension if you inject XUL content into HTML pages. You shouldn’t be doing this anyway…
Implement Xrays to Object objects, Implement Xrays to Array objects. This extends an important security barrier between privileged and unprivileged code, called Xray Vision. In a nutshell, it protects privileged scripts from running unexpected code when calling familiar functions in content code, like
window.alert, which can be replaced by page scripts. It ensures that you always call the original function.
For better separation between privileged and unprivileged code, we recommend that you start looking into the Message Manager. We will be writing more about it soon, because using the Message Manager will be necessary when Firefox moves to a multi-process architecture (known as Electrolysis or e10s for short). The sooner you start using it in your add-on, the better.
- HTTP cache v2: disable addon access to cache v1 IDLs. This removed the majority of the previous cache storage interfaces in favor of the new ones. For more information, read this blog post and the documentation on MDN.
- Remove main-thread I/O from password manager. The API to access the Login Manager remains mostly unchanged, but the storage backend is now asynchronous and JSON-based. This also includes a change that makes
modifyLoginvalidate its input just like
- Remove nsCharsetAlias and nsCharsetConverterManager. It doesn’t look like any AMO add-ons are using these interfaces, but I’ll document this change just in case.
- Provide add-ons a standard directory to store data, settings. Most add-on devs know that they should store their data somewhere in the profile directory (preferences should only store small configuration values), but we don’t have a clear standard for this, or a good storage API. This first step establishes a standard directory: [profile]/extension-data/[add-on ID]. The follow-up bug will implement an API to make it easier to store data in that folder. For now, you should consider migrating your data to the new location. Kudos to Alex Vincent for the great work!
Please let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 32, I’d like to know.
The automatic compatibility validation and upgrade for add-ons on AMO will happen soon, so keep an eye on your email if you have an add-on listed on our site with its compatibility set to Firefox 31.