I’m looking at updating an existing extension to work properly in multiprocess Firefox. My current extension uses js-ctypes to load (ctypes.open) and call methods (ctypes.declare) in a dll. The documentation on adapting to multiprocess Firefox recommends avoiding the use of this low level API. The other option that I know of is to call runtime.sendNativeMessage in the WebExtensions API, but Mozilla’s documentation indicates that this will not be supported. Are there other options? Does anyone know how long the low level APIs will be supported?
I don’t think they say to avoid ctypes. For the exact abilities ctypes gives you, there isnt an alternative really.
Lots of times (especially on Macs and GTK systems) you have to run code on the mainthread. So you can continue to use it. Ideally you run what you can off the mainthread with a ChromeWorker/PromiseWorker.
https://developer.mozilla.org/en-US/docs/Web/API/PromiseWorker
I use ctypes here in an e10s friendly way - https://github.com/Noitidart/MouseControl
Whats friendly about it is that I run the ctypes, is that whatever can run in the worker does. I run the mainthread stuff in bootstrap.js which is the main process. You can run ctypes from framescripts (within the tab process) though if you want.
There is child_process however. If you have an external thing you need to communicate with - https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process
Thanks for the reply. That makes me feel better about using ctypes. My current extension does not work properly in multiprocess Firefox, so I am moving to the high level APIs instead of the XUL stuff. It’s good to know I can still use the ctypes to communicate with my DLL.
If you are using the addon SDK, sticking with the high-level APIs should automatically mean your addon works in multiprocess mode. Mozilla are also (so far) committed to supporting the high-level API.
The low-level APIs give you functionality which may not be compatible with multi-process Firefox, and you would have to make special arrangements for your code to work. Mozilla has also announced that the low-level APIs will not necessarily be supported in the future, as part of the move to the new WebExtensions framework for addons. In practice, Mozilla are already removing certain features and not providing a replacement for the functionality, although it is not yet official policy to deprecate support for XUL addons and SDK low-level APIs.
So if you can do something with a high-level API, that is best. If not, then use the low-level API and be prepared to rework it in a year or two (or maybe three).