Firefox 33 will be released on October 14th. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 33 for Developers, so you should also give it a look.
- Remove JSD. This finally removes the old JS debugging API, whose main client was the very popular Firebug extension. The new debugger API that replaced it has been around for a while and Firebug already migrated to it.
- Print a deprecation warning when importing XUL into content documents. Injecting XUL into HTML documents will not be supported anymore, and this introduces a deprecation warning to give developers time to migrate to a different solution. Injecting HTML is the easiest alternative.
- Remove NSS-based certificate verification. From a comment in the bug: “add-ons that are trying to use CERT_VerifyCert, CERT_VerifyCertificate, CERT_PKIXVerifyCert, or other NSS functions that call those functions are likely to run into problems”. This should only affect binary add-ons that use NSS.
- Build nss when MOZ_FOLD_LIBS with minimal set of exported symbols. More changes that could affect add-ons that tap into NSS.
- Make nsISessionStore’s functions throw for non-strings, for consistency with SessionStore.jsm. This affects the following functions:
setGlobalValue. Their third argument should be a string, and passing anything else will most likely throw.
- Merge nsIX509Cert2 and nsIX509Cert3 into nsIX509Cert.
- HTMLMediaElement doesn’t inherit from nsIDOMHTMLMediaElement. This removes the interfaces
- Remove CMS support from Firefox builds of PSM. This should only affect add-ons that used the nsICMS* interfaces to handle secure email. Fairly niche, but some add-ons were affected by it.
- Remove nsIRecentBadCerts and implementation.
- Add a field to install.rdf for add-ons that are compatible with electrolysis. The multiprocessCompatible flag was added to install.rdf so that you can declare that your add-on works with the new Electrolysis (e10s) multiprocess mode without any compatibility shims. So, even if you activate e10s on Nightly builds, you can’t be sure that your add-on works well with e10s until you run it with that flag set to true. The compatibility shims are temporary and bad for performance, so please make sure to test your add-on and set that flag as soon as possible! You can read more about e10s compatibility here. Note that, while the flag was introduced in Firefox 33, e10s is still being worked on and disabled by default, and we’re not sure yet when it will make it to release. We will keep you up to date on this blog.
Please let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 33, 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 32.