Hello!
Is there currently a way to interact with native APIs or applications through web extensions?
I’m thinking about mechanisms like chromes native messaging or js-ctypes.
If not, what is the schedule to introduce features of this kind to FireFox’s web extensions?
Best regards
Thomas
For JPM, child_process works: https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process
So maybe you want to do a JPM addon for now. I don’t think child_process has been brought to webext yet.
Do you have any js-ctypes work where you set up IPC, would be cool to see two way pipes via js-ctypes. It’s on my to do list. I need it for my file watcher: https://github.com/Noitidart/jscFileWatcher
No, sorry. I have a chrome extension which uses native messaging that I need to port to FireFox. Going the web extension route looked natural to me until I reached this critical point.
I don’t think the JPM APIs are available. Maybe I’m doing it wrong, but require() never seems to be defined in the context of my web extension-scripts.
permissions
Firefox does not yet support the following permissions:
I think only option right now is JPM. But webext dev is going fast and should be around soon. Bugzilla can help us estimate a date.
A few things, first, WE is in active development, and the blog announcing it gave it 12-18 months, given the release schedule movements of things like enforced signing and e10s, I’d give it 18-24 months minimum. Second thing, you may want to submit a request that they work on it as a priority here: https://webextensions.uservoice.com/forums/315663-webextension-api-ideas
Third, last I heard WE is only in Nightly, and not even in Dev Edition yet, so even if it works, very few people will be able to use your addon.
Thank you for the clarification. Guess I’ll have to dive into Jetpack 
Maybe you can try this:
var { require } = Cu.import( "resource://gre/modules/commonjs/toolkit/require.js", {} );If you do end up wanting to use addon-sdk, here is a video tutorial (55min) but it shows you how to go from start to finish. Including localization by the babelzilla community: https://github.com/Noitidart/Firefox-on-OS-X-Icon
But what @MartinJ is saying is a good idea ( I didnt think of that! ), port everything to WebExtesnsion, but then use chrome privelages to grab in child_process and use it.
This is how to do that (this is basically how you use sdk stuff in non-sdk classic bootstrap method, which should also work in WebExtensions)
// Import SDK Stuff
const COMMONJS_URI = 'resource://gre/modules/commonjs';
const { require } = Cu.import(COMMONJS_URI + '/toolkit/require.js', {});
var child_process = require('sdk/system/child_process');
var iconutil = child_process.spawn('/usr/bin/iconutil', aArgs);
iconutil.stdout.on('data', function (data) {
console.error('iconutil stdout:', data);
});
iconutil.stderr.on('data', function (data) {
console.error('iconutilstderr:', data);
});
iconutil.on('close', function (code) {
console.error('iconutil exited with code', code);
});Thanks for the ideas.
Unfortunatly the “Cu” object doesn’t seem to be available in the context of webextensions.
Sorry, should have said Components.utils instead of Cu, try that.
I tried that as a fallback. As it stands the Component object only has one member (interfaces) which also has only one member (nsIDOMCSSRule). The rest, especially the utils-stuff, is missing.
Maybe this is intentional as it keeps devs from mixing APIs in their extensions?
Thomas,
I’m not sure why js-ctypes is not working for you. We had a similar requirement in that we needed an extension to call functions in a dll. For a Chrome extension, we went the native messaging route, but in our Firefox extension, we use ctypes to call our dll. This was actually simpler in our case. What problems are you having with ctypes?
Wayne
At the moment there’s no access to native APIs on WebExtensions, but you can do so from SDK and XUL extensions. Most suggestions in this thread are for SDK and XUL extensions.
Currenty we are using bootstrapped extension which uses native APIs. After this announcement https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ we plan to move to WebExtensions. So, if there’s no access to native APIs on WebExtensions, what’s the way to go? Can we use a hybrid architecture (keep bootstrap.js and also have manifest.json)?
Thanks,
Panagiota
Are you aware of https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Two_Types_of_Scripts ?
require, exports is available in add-on scripts, but not in content scripts.
There’s no access to native APIs now, but there will be access in the future, probably. For now, I suggest you continue with your bootstrapped version.