Add-on Compatibility for Firefox 34

Nov 13 2014

Firefox 34 will be released on November 25th. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 34 for Developers, so you should also give it a look.

General

UPDATE: New search UI. Please read this post about the new search UI, which landed fairly late in the beta cycle.
Get Firefox to launch with the new .app bundle structure. Because of new requirements in Mac OS internal application layout, some changes needed to be made in the structure of the application package. For add-on developers, it means that you might need to change your code if you referenced the special directory “GreD” to obtain access to certain binaries in the Firefox package. Those binaries were moved to a new special directory “GreBinD”. Non-binary files should still be accessible through “GreD”.
Remove localstore.rdf. As part of a larger effort to remove most RDF code from Firefox, the contents of localstore.rdf have moved to xulstore.json. This means your add-on won’t work if you’re tapping directly into the RDF store for this data.
Whitelist XBL bindings that may be applied to untrusted content. XBL binding declarations will need to include bindToUntrustedContent="true" if they should work in untrusted (web) content.
JavaScript regular expression captures broken with alternation in some cases.

XPCOM

Implement nsIDOMStorage with a proxy. This essentially adds a window argument to the createStorage function.
Remove SetCharsetForURI and GetCharsetForURI from nsINavHistoryService. These functions can now be found in PlacesUtils, but they return a Promise instead of the value directly.
Add an assertion to XMLDocument to ensure that that callingDoc and the doc have the same principal. In short, add-ons should be using XMLHttpRequest instead of XMLDocument to load documents.
Merge nsIMarkupDocumentViewer into nsIContentViewer.
Remove enumeration methods from nsICommandParams.
Make min/max/bucket_count optional for nsITelemetry newHistogram() / registerAddonHistogram().

New!

Import and use public domain JNI.jsm implementation. This is a useful module for Android add-on developers that need low-level access. It has been renewed with a more complete implementation. You can get the module with Components.utils.import("resource://gre/modules/JNI.jsm");

Please let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 34, 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 33.

10 responses

Kohei Yoshino wrote on November 14, 2014 at 10:40 am:

Japanese translation: https://dev.mozilla.jp/2014/11/firefox-34-addon-compatibility/
Andres Ruiz wrote on November 19, 2014 at 3:48 pm:

I really think its been some time that Firefox hasn’t had a compatible Spanish (Mexico) language pack with resent versions. is would be very useful if it was. I’m not sure if this the right place or procedure but I don’t have the time to register on the add-on forum.
Thank you
1. Jorge Villalobos wrote on November 20, 2014 at 12:12 pm :
  
  It looks like this one is kept up to date.
matt mcccarty wrote on November 22, 2014 at 3:32 am:

how can i keep track of all my apps on my phone
bdhr wrote on December 3, 2014 at 12:37 pm :

> If your add-on breaks on Firefox 34, I’d like to know.

My extension (not on AMO, but on the BitBucket page linked to my name*) works** in Fennec 33.1 but not in 34.

It installs and the preferences are available but the changes I make to the DOM in my pagemods don’t take effect.

I get errors like these in logcat:

E/GeckoConsole( 1273): [JavaScript Error: “t is not defined” {file: “resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///data/data/org.mozilla.firefox/files/mozilla/orxe1i7e.default/extensions/jid0-xABZkhS0Qpa6BSx8QQu15jrIUUk@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/windows/tabs-fennec.js” line: 162}]

E/GeckoConsole( 1273): [JavaScript Error: “[Exception… “Component does not have requested interface” nsresult: “0x80004002 (NS_NOINTERFACE)” location: “JS frame :: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///data/data/org.mozilla.firefox/files/mozilla/orxe1i7e.default/extensions/jid0-xABZkhS0Qpa6BSx8QQu15jrIUUk@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/tabs/utils.js :: isFennecTab :: line 42″ data: no]”]

For reference, it works fine on desktop Firefox 34.

If you can provide any help, I’d appreciate it.

*In case you attempt to test it, note that by default, the extension, including the XPIs on the downloads page, doesn’t work on mobile, because I use the panel module. Right now I use the kludge of a script buildmobile.py to strip out the panel usage temporarily, build an XPI, and add the panel back in. If there’s a way to do this at runtime instead please let me know.

**Technically, some functionality is broken in git on Firefox < 34 because I recently started using (unprefixed) Element.matches(), but that's beside the point.
1. bdhr wrote on December 3, 2014 at 12:38 pm :
  
  Oh, and this is on both SDK 1.16 and 1.17.
willf wrote on December 4, 2014 at 3:28 pm:

Firefox 34 broke the flashblock add-on. This is a real drag as I depend on that add-on preventing websites from draining the battery on my laptop and using up my CPU resource. As an aside, perhaps this sort of control (allowing/blocking flash from playing automatically) should be built into FIrefox? I, for one, would appreciate that.
1. J. McNair wrote on December 5, 2014 at 6:08 pm:
  
  It is built-in, just not easy to find. It’s also not quite as
  Firefox button -> Add-ons -> Plugins
  On the dropdown, next to Shockwave Flash, choose “Ask to Activate”
  
  Now, every web site with Flash will have a gray bar asking if you want to allow it. If you select “Continue blocking”, then every Flash object will have a gray box asking to activate it.
  1. willf wrote on December 10, 2014 at 7:47 am:
    
    I see. I guess the issue with the native flash blocking method is that it doesn’t support a whitelist of sites allowed to play flash unlike flashblock. If native flash (or other plugin) blocking supported whitelisting I’d drop flashblock.
2. Don wrote on December 5, 2014 at 7:26 pm:
  
  I agree. If you are on a slow connection Flash KILLS you.
  It should be a standard feature.