4

Chrome and Firefox have announced that they will be dropping support for NPAPI plugins soon.

See http://techcrunch.com/2013/09/23/say-goodbye-to-npapi/

For Chrome, I have a couple of options like moving to Native Client (NaCl) if I want to execute some C++ code from JavaScript.

But what are my options in Firefox?

So basically, I have a Firefox add-on built using the Add-on SDK and I want to invoke some C++ code from the add-on content script (JavaScript). I was using NPAPI before but now I want to move to something that is going to be supported more longer term.

Thanks in advance.

Georg Fritzsche
  • 97,545
  • 26
  • 194
  • 236
user2816406
  • 43
  • 1
  • 4
  • 1
    From what I can gather that post has been discredited in its comments relating to Firefox. The source he links to doesn't say that at all. There is a google blog post here http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html that says NPAPI is going to be removed from Mozilla but again the source he links to says nothing of the sort. I can't see any statement like this from Mozilla and would be interested if anyone has seen one. – Andy Nov 12 '13 at 11:48

1 Answers1

5

Installing an NPAPI plugin just to "invoke some C++ code" is actually not a good thing. NPAPI plugins will be available to all websites, not just your add-on... Did you make sure that the stuff won't break if random websites access it in ways you didn't expect?

Anyway, there are different mechanisms for running binaries code in Firefox today:

  1. js-ctypes is the least painful and recommended way. Basically, you would define a C API/ABI that you can import into and interact with in Javascript.
  2. XPCOM binary components. Basically the whole Firefox backend is written or glued together using binary XPCOM components. It is possible to implement them in add-ons as well, although it is a pretty steep learning curve to get started and the documentation is scattered around many places and pretty much "incomplete". Another huge drawback is that you need to recompile and re-test your modules for each new Firefox version (not the case with js-ctypes).

Using the Add-on SDK will complicate matters further, but you should be used to that already since you're using NPAPI plugins right now.

I'd recommend that you first determine if you really need binaries in your add-on, or if a JS implementation (with modern features, such as typed arrays, and maybe even asm.js via emscripten) and HTML5 (canvas, audio/video) would do as well. And if not, if at least light-weight js-ctypes would do.

Furthermore, NPAPI plugins in Firefox are not going away just now. For the time being they will be available, but a user will have to enable them (Click-to-play). Add-ons could probably work around this, enabling them as needed, for now. So there is no need to rush things.

nmaier
  • 32,336
  • 5
  • 63
  • 78
  • "js-ctypes is the least painful and recommended way. Basically, you would define a C API/ABI that you can import into and interact with in Javascript." from what I read js-ctypes can only be accessed from chrome code and hence I guess this can't be used in content scripts or can it be ? so is communicating between content script and addon script and vice-versa (for results) the only way here for every native call that we need to make ? thanks to clarify the answer further. – user2824332 Sep 27 '13 at 17:45
  • Yes, your content script would need to ask the privileged script (`main.js`) to call js-ctypes functions and pass the result back. – nmaier Sep 30 '13 at 20:43
  • XPCOM binary components deprecated a long ago by Mozilla. **js-ctype** only alternative in Mozilla platform... – gavenkoa Nov 25 '13 at 17:45