Firefox 32 附加组件兼容性

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.

General

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

Content scripts


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.

XPCOM

• 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 modifyLogin validate its input just like addLogin.
• 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.

New!

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

http://blog.mozilla.org/addons/2014/08/14/compatibility-for-firefox-32/