Add-on Compatibility for Firefox 33

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.

General

XPCOM

New!

  • 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.

16 comments on “Add-on Compatibility for Firefox 33”

  1. Kohei Yoshino wrote on

    Japanese translation is here: https://dev.mozilla.jp/2014/10/firefox-33-addon-compatibility/

    1. Jorge Villalobos wrote on

      Awesome!

  2. Mook wrote on

    NSS was also usable from JS-ctypes (I guess that’s kinda binary?); it’s a C API, so it didn’t have to change between platforms. It probably have glaring issues around shutdown, though, since JS-ctypes doesn’t have a good hook for that.

    I don’t think I actually touched the cert verification stuff, though, just PKI. Limiting the set of exported functions, however, might affect things.

    (As far as I know, my possible user count is… 1. So it doesn’t matter a lot for my particular case; however, it might affect similar people; that’s your judgment call.)

  3. Michael wrote on

    We had already a short chat in IRC concerning performance issues with Firefox 33 beta 8. I filed bug #1077030 for this. It turned out, that the problem is caused by graphics changes. For me Firefox 33 is unusable and I’m sure that many other users will have the same problem. Unfortunately there is no reaction from the developer until now.

    1. Jorge Villalobos wrote on

      I’m glad the cause of the problem was identified. OMTC is a fairly big feature and I know there are significant stability and performance tradeoffs for both enabling or disabling it. That’s not to say that your bug is invalid, but it needs to be looked at by someone who knows about it, and it appears the right person has been asked to chime in. It might be a while before you hear back, though.

      1. Michael wrote on

        Thanks for your answer. I don’t understand why I feature with such an impact is enabled short before release date (until beta7 it was disabled) and why there is no reaction if users report problems.

        1. Jorge Villalobos wrote on

          With such a large user audience, any feature we introduce is bound to break something for a bunch of people. It’s always a matter of balancing the benefits of a new feature with its potential and known negative effect.

  4. Luke wrote on

    Is it just me, or is Firefox 33 beta a bit unstable with Browser Toolbox compared to earlier releases? I noticed the debugger breakpoints not stopping, and the inspector-button-toggle rarely would do anything but make the main Firefox window unresponsive.

  5. Gonzalo wrote on

    Totally unstable on my windows 7

    1. Jorge Villalobos wrote on

      If you’re having problems with crashes or black screens, they are being investigated. However, it would be useful if you let me know what problem you’re experiencing, since we might need more cases to look into.

  6. Mindaugas wrote on

    You missed https://bugzilla.mozilla.org/show_bug.cgi?id=673569 even though it had ‘addon-compat’ flag.

    Frames scripts now don’t share their scope by default. My Addon was affected on Android and in turn will be affected on Firefox once I transition away to e10s.

    I had to explicitly define the shared add-on namespace (with util methods etc) on ‘this’. It’s too complicated to have self-sufficient content scripts in my case.

    1. Mindaugas wrote on

      Apparently one can get the previous behavior by passing another boolean flag to messageManager.loadFrameScript:
      https://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIMessageManager.idl#391

      MDN docs are behind on that one 😉

      1. Jorge Villalobos wrote on

        Thanks for the info. That bug had a milestone for Firefox 29, so it wouldn’t appear on this post. However, I checked the one for 29 and I didn’t mention it then. Probably because there was a very big focus on Australis and maybe because there were few add-ons using frame scripts. We will definitely be talking more about e10s in the future.

  7. joaquin wrote on

    There are more functions removed from NSS, for example:

    – SECMOD_UpdateSlotList (no workaround found, must use PKCS11 low level)
    – PK11_FindPrivateKeyFromCert (use PK11_FindKeyByDERCert)
    – PK11_GetSlotFromPrivateKey (use PK11_ReferenceSlot(key->pkcs11Slot) where key is SECKEYPrivateKey *key )

    Why not leave NSS as it is???

    Each release I must check what functions was removed and test it on Linux, MacOSX and Windows!!!!

    My code grows and grows and grows, only to patch FFNSS.

    Who dedices not to export these NSS functions in nss3 native library?

    1. Jorge Villalobos wrote on

      I’m not very familiar with NSS, so you should ask the right people. The bug should give you an idea as to why these changes are being made and who is making the calls there.

  8. Michael Kaply wrote on

    One more (from the release notes):

    The interface nsIX509CertDB2 has been removed and the methods from that interface have been moved to the nsIX509CertDB interface.

    This was a late add on October 15.