Mozilla Add-ons Community Blog
Categories: compatibility developers documentation

Dropping support for binary components in extensions

10 responses

Update: this change has been pushed back to Firefox 41 rather than 40.

Starting with Firefox 40 41, scheduled to be released in August this year, binary XPCOM support for extensions will be dropped.

Binary XPCOM is an old and fairly unstable technology that a small number of add-on developers have used to integrate binary libraries into their add-ons, sometimes to tap into Firefox internals (hence the unstable part). Better technologies have become available to replace binary XPCOM and we have encouraged developers to switch to them. From the original post:

Extension authors that need to use native binaries are encouraged to do
so using the addon SDK “system/child_process” pipe mechanism:
https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process

If this is not sufficient, JS-ctypes may be an alternative mechanism to
use shared libraries, but this API is much more fragile and it’s easy to
write unsafe code.

Developers who rely on binary XPCOM should update their code as soon as possible to prevent compatibility issues. If you have any questions or comments about this move, please do so in the mozilla.dev.extensions newsgroup.

10 comments on “Dropping support for binary components in extensions”

  1. Kohei Yoshino wrote on

    Japanese translation: https://dev.mozilla.jp/2015/05/dropping-support-for-binary-components/

  2. Mook wrote on

    Just wanted to mention that this post (and the last one, possibly others) are missing from planet.mozilla.org; it looks like it’s bug 1160609. Probably want to make sure this propagates in the usual ways 🙂

    1. Jorge Villalobos wrote on

      Oh, lame.

      1. mhoye wrote on

        Resolved now.

  3. Avi wrote on

    Is https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/XPCOMUtils.jsm getting deprecated as well?

    1. Jorge Villalobos wrote on

      No. That JS module is mostly for non-binary XPCOM components, so it’ll continue to work.

  4. Noitidart wrote on

    How is jsctypes fragile? 🙁 I don’t like baby getting a bad rep 😛

    Isn’t system_child_process a js-ctype thing?

    1. Jorge Villalobos wrote on

      It’s fragile in that you can still do things incorrectly and cause instability, and potentially crashes. system_child_process is for running external processes, rather than tapping into native libraries.

  5. Tito wrote on

    Will that affect Thunderbird as well, especially the components related to the address book?

    Titto

    1. Jorge Villalobos wrote on

      There was some discussion about not doing this for Thunderbird, but I haven’t seen a bug to make this change.