Closed Bug 1190682 Opened 9 years ago Closed 8 years ago

[tracking] Implement |connectNative| for open extension API

Categories

(WebExtensions :: Untriaged, defect, P1)

Product:
WebExtensions
Component:
Untriaged
Version:
34 Branch
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: billm, Assigned: aswan, Mentored)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, meta, Whiteboard: [runtime]triaged)

Priority: -- → P1
Component: Extension Compatibility → WebExtensions
Product: Firefox → Toolkit
Whiteboard: [runtime]
Depends on: webext-runtime
Flags: blocking-webextensions-
Is there some architectural direction on how this might be implemented?

Port implementation uses messageManager
 - currently runtime connect/sendMessage 
   provide Services.cpmm "@mozilla.org/childprocessmessagemanager;1" 

seems like introduction of nataveMessageManager with same interface would be reasonable?
I'm keen on seeing this feature ship and am happy to write code to make it happen if no-one else has plans to work on this, but it would be my first contribution to Firefox.

I found the ext-runtime.js file, so I can roughly see how the existing code worked, and I've written some code to read the native manifest from some registry/file locations based on what Chrome does.

From there it seems like I should be able to use subprocess.js to launch the native process and talk chrome's native messaging protocol to it.

However, I'm not entirely sure how to implement a nativeMessageManager though.

If you guys could provide some guidance on whether this plan seems sane and how I should proceed with the nativeMessageManager bits, I'd like to help work on this.
I would like this as well, it replaces ctypes for us.

One thing to watch out for: dealing with anonymous pipes under windows is rather painful (low level reads don't block on an empty pipe for example) and we had to implement a hacky workaround in the Chrome version of our extension - If you get this working properly, please include a windows C/C++ example client in the documentation. You will save many people a lot of pain.
So I've been playing with ExtensionUtils.jsm and ext-runtime.js, working with the subprocess from addon-sdk (implemented via js-ctypes?)  and have the following hacked together.

This launches my chrome app, which can read the input from firefox, but the result doesn't come back well, I beleive because https://bugzilla.mozilla.org/show_bug.cgi?id=1180409  where the leading header for the string size having null values is causing the string to be clipped.


// Abstraction for a Port object in the extension API. Each port has a unique ID.
function NativePort(context, messageManager, name, id, sender) {
  this.context = context;
  this.messageManager = messageManager;
  this.name = name;
  this.id = id;
  this.listenerName = `Extension:Port-${this.id}`;
  this.disconnectName = `Extension:Disconnect-${this.id}`;
  this.sender = sender;
  this.disconnected = false;
  this.child_process = null;
  
  this.messageManager.addMessageListener(this.disconnectName, this, true);
  this.disconnectListeners = new Set();
}

NativePort.prototype = {
  api() {
    let portObj = Cu.createObjectIn(this.context.cloneScope);

    // We want a close() notification when the window is destroyed.
    this.context.callOnClose(this);

    let publicAPI = {
      name: this.name,
      disconnect: () => {
        this.disconnect();
      },
      postMessage: msg => {
        if (this.disconnected || !this.child_process) {
          throw new this.context.contentWindow.Error("Attempt to postMessage on disconnected port");
        }
		// JSON.stringify doesn't support a root object which is undefined.
		if (msg === undefined)
		  msg = null;
		msg = JSON.stringify(msg);
		if (msg === undefined) {
		  // JSON.stringify can fail with unserializable objects. Log an error and
		  // drop the message.
		  //
		  // TODO(kalman/mpcomplete): it would be better to do the same validation
		  // here that we do for runtime.sendMessage (and variants), i.e. throw an
		  // schema validation Error, but just maintain the old behaviour until
		  // there's a good reason not to (http://crbug.com/263077).
		  console.error('Illegal argument to Port.postMessage');
		  return;
		}
		var i = msg.length;
		var header="";
	header += String.fromCharCode(i & 0xFF);
	header += String.fromCharCode(i >>> 8);
	header += String.fromCharCode(i >>> 16);
	header += String.fromCharCode(i >>> 24);
		msg = header+msg;
		console.log("postMessage " + msg);
		emit(this.child_process.stdin, 'data', msg);
//		emit(this.child_process.stdin, 'end');
//		this.child_process.stdin.write();
      },
      onDisconnect: new SingletonEventManager(this.context, "Port.onDisconnect", fire => {
        let listener = () => {
          if (!this.disconnected) {
            fire();
          }
        };

        this.disconnectListeners.add(listener);
        return () => {
          this.disconnectListeners.delete(listener);
        };
      }).api(),
      onMessage: new SingletonEventManager(this.context, "Port.onMessage", fire => {
        let listener = ({data}) => {
          if (!this.disconnected) {
            fire(data);
          }
        };

        this.messageManager.addMessageListener(this.listenerName, listener);
        return () => {
          this.messageManager.removeMessageListener(this.listenerName, listener);
        };
      }).api(),
    };

    if (this.sender) {
      publicAPI.sender = this.sender;
    }

    injectAPI(publicAPI, portObj);
    return portObj;
  },

  connect(executable) {
	this.child_process = spawn(executable);
	this.child_process.stdin.setEncoding ('binary');
	this.child_process.stdout.setEncoding ('binary');
	this.child_process.stdout.on('data', function(data) { 
  // Issue here - stdout.on seems to have cut at the null.
	  console.log( "onData " + data); 
	  var header = data.slice(0, 4);
      data = data.slice(4);


        var dl = (header[3] << 24) | (header[2] << 16) | (header[1] << 8) | header[0];
        if ((dl < 0) || (dl > data.length)) {
            alert("Message (length " + data.length + ") truncated.  " +
                dl + " characters expected.");
        }
	  this.messageManager.sendAsyncMessage(this.listenerName, data);  // Issue here - this.messageManager not available?
	});
  },
  
  handleDisconnection() {
    this.messageManager.removeMessageListener(this.disconnectName, this);
    this.context.forgetOnClose(this);
    this.disconnected = true;
  },

  receiveMessage(msg) {
    if (msg.name == this.disconnectName) {
      if (this.disconnected) {
        return;
      }

      for (let listener of this.disconnectListeners) {
        listener();
      }

      this.handleDisconnection();
    }
  },

  disconnect() {
    if (this.disconnected) {
      throw new this.context.contentWindow.Error("Attempt to disconnect() a disconnected port");
    }
    this.handleDisconnection();
//    this.messageManager.sendAsyncMessage(this.disconnectName);
	this.child_process.kill();
  },

  close() {
    this.disconnect();
  },
};


  connectNative(messageManager, appName, executable) {
    let portId = this.broker.makeId();
    let port = new NativePort(this.context, messageManager, appName, portId, null);
//    let msg = {name, portId};
//    this.broker.sendMessage(messageManager, "connect", msg, this.sender, recipient);
	port.connect(executable);
    return port.api();
  },


ext-runtime
	  
	  connectNative: function(appName) {
        if (typeof(appName) !== 'string') {
          throw new Error('Invalid arguments to connectNative.');
        }
		// translate appname to application, check extension control list
		var executable = 'C:\\Program Files\\NetIQ\\SecureLogin\\slchromehost.exe';
		// create the port with id in port list
		// run the application 
        return context.messenger.connectNative(Services.cpmm, appName, executable);
	  },
Flags: needinfo?(wmccloskey)
I would like to see this added to the list of required fixes for release 1.0 of WebExtensions. I am the developer in charge of maintaining the Firefox addon for Dragon speech recognition. We use the nativeMessaging API in our Chrome extension as a way to replace the plugin capability we lost when Chrome stopped supporting NPAPI. I am sure we are not the only one to use this solution.
I recently realised I can probably live without this by simply making a HTTP wrapper around my native component and making XHR requests to localhost, and I think I will use this approach rather than connectNative even once it is done since the Safari equivalent has too many restrictions for me to want to use it, and I have a greenfield extension.
Whiteboard: [runtime] → [runtime]triaged
I'd like to have this feature available in WebExtensions 1.0. I'm a developer of a native plugin which still uses NPAPI. With connectNative there will be an alternative solution.

Please add runtime.connectNative before NPAPI get's disabled!
Flags: blocking-webextensions+
Flags: blocking-webextensions+ → blocking-webextensions?
Flags: blocking-webextensions? → blocking-webextensions-
Whilst we agree this is useful, there isn't the time to work on this the resources available. If someone else is willing to work on it for that time frame, we'd reconsider that.
Please make sure that this functionality is available BEFORE NPAPI is disabled in Firefox. This is the solution we used for our Chrome extension.

Is there a way that Mozilla can list this as a must have before NPAPI is disabled?
How could I get involved to help implement this feature?
(In reply to nuancedragondev from comment #10)
> How could I get involved to help implement this feature?

If you haven't built Firefox before, that's the place to start. The simplest
way to do that is explained here:

https://developer.mozilla.org/en-US/docs/Artifact_builds

Patches are more than welcome, probably a brief overview of how this would get implemented and/or a prototype would be a really good start.

Other people working on webextensions would be happy to help. You can contact them here:

https://wiki.mozilla.org/Add-ons#Getting_in_touch

If you do want to take this on, we'll find a mentor to help you out.
Mentor: wmccloskey
Please also provide validation of the manifest file and the native messaging host executable. Without it, the add-on has no way to validate the host that it's communicating with. Here's a bug in Chromium's tracker describing the issue and including their responses: https://bugs.chromium.org/p/chromium/issues/detail?id=514936 The very short version is that Chrome's attitude allows any process to edit the native messaging host manifest file to point to a different executable or change the allowed origins. The Chromium team has decided that this is not within the security model of Chrome, and I hope Firefox will provide a better answer to this issue.
Continuing from comment #5 Resolved my issue with binary data coming back, had to use a different method to set the channel to binary

  connect(executable) {
	//  console.info('NativePort.connect');
	let options = {
      encoding: null
    };// encoding:binary  use null
	this.child_process = spawn(executable,null,options);
	this.child_process.stdout.on('data', data => { 
	  var header = data.slice(0, 4);
      data = data.slice(4);
	  console.log( "onData data " + data); 


        var dl = (header[3] << 24) | (header[2] << 16) | (header[1] << 8) | header[0];
        if ((dl < 0) || (dl > data.length)) { 
            alert("Message (length " + data.length + ") truncated.  " +
                dl + " bytes expected.");
        } else {
			data = data.slice(dl);
		}// trim or force dl === data.length?
		
		console.log( "onData listener " + this.listenerName + " : data " + data); 
		
	  this.messageManager.sendAsyncMessage(this.listenerName, JSON.parse(data));
	});
  }

The sendAsynMessage doesn't seem to be working.  Initially I found that this.listenerName was coming up empty, I'm obviously not understanding difference between  function(data) and data =>  function construction.
(In reply to Jamie Phelps from comment #12)
> Please also provide validation of the manifest file and the native messaging
> host executable. Without it, the add-on has no way to validate the host that
> it's communicating with. Here's a bug in Chromium's tracker describing the
> issue and including their responses:
> https://bugs.chromium.org/p/chromium/issues/detail?id=514936 The very short
> version is that Chrome's attitude allows any process to edit the native
> messaging host manifest file to point to a different executable or change
> the allowed origins. The Chromium team has decided that this is not within
> the security model of Chrome, and I hope Firefox will provide a better
> answer to this issue.

Jamie,

Do you have a concrete suggestion for what we might do?  I agree with the Chrome maintainers' point that if a process has access to the filesystem and registry, there are many things they can do to subvert the browser so working on this one particular scenario seems fruitless.
I'm happy to discuss it further, but I'm turning this bug into a tracker, if you want to follow up can you please file a new bug and make it a blocker of this one?
Flags: needinfo?(wmccloskey)
Summary: Implement |connectNative| for open extension API → [tracking] Implement |connectNative| for open extension API
Depends on: 1267362
Created a wiki page for this project here: https://wiki.mozilla.org/WebExtensions/Native_Messaging
See Also: → 1268594
Depends on: 1269501
Depends on: 1270356
Depends on: 1270357
Depends on: 1270359
Depends on: 1270360
Blocks: webext-runtime
No longer depends on: webext-runtime
Depends on: 1272522
(In reply to nuancedragondev from comment #10)
> Please make sure that this functionality is available BEFORE NPAPI is
> disabled in Firefox. This is the solution we used for our Chrome extension.
> 
> Is there a way that Mozilla can list this as a must have before NPAPI is
> disabled?
> How could I get involved to help implement this feature?

@nuancedragondev - there is js-ctypes which you can start using right away in place of NPAPI. I have replaced NPAPI stuff with js-ctypes already.
(In reply to noitidart from comment #16)
> (In reply to nuancedragondev from comment #10)
> > Please make sure that this functionality is available BEFORE NPAPI is
> > disabled in Firefox. This is the solution we used for our Chrome extension.
> > 
> > Is there a way that Mozilla can list this as a must have before NPAPI is
> > disabled?
> > How could I get involved to help implement this feature?
> 
> @nuancedragondev - there is js-ctypes which you can start using right away
> in place of NPAPI. I have replaced NPAPI stuff with js-ctypes already.

I would prefer a cross-browser implementation via NativeMessaging as i think this will be the final way in future to communicate with native applications working in all modern browsers. I don't want to temporary use a Firefox proprietary API for this.
(In reply to Dominik from comment #17)
> (In reply to noitidart from comment #16)
> > (In reply to nuancedragondev from comment #10)
> > > Please make sure that this functionality is available BEFORE NPAPI is
> > > disabled in Firefox. This is the solution we used for our Chrome extension.
> > > 
> > > Is there a way that Mozilla can list this as a must have before NPAPI is
> > > disabled?
> > > How could I get involved to help implement this feature?
> > 
> > @nuancedragondev - there is js-ctypes which you can start using right away
> > in place of NPAPI. I have replaced NPAPI stuff with js-ctypes already.
> 
> I would prefer a cross-browser implementation via NativeMessaging as i think
> this will be the final way in future to communicate with native applications
> working in all modern browsers. I don't want to temporary use a Firefox
> proprietary API for this.

Yep, we certainly want something that works consistently across browsers.
The W3C browserext community group [1] has agreed to work on a specification for native messaging [2].
But we'll still be implementing this in Firefox to provide an option for folks currently relying on NPAPI (see comment 6 and comment 8 for instance).  As a cross-browser standard emerges, I expect we'll be able to support it relatively easily and quickly.

[1] https://www.w3.org/community/browserext/
[2] https://github.com/browserext/browserext.github.io/issues/5
Depends on: 1274708
(In reply to Dominik from comment #17)
> (In reply to noitidart from comment #16)
> > (In reply to nuancedragondev from comment #10)
> > > Please make sure that this functionality is available BEFORE NPAPI is
> > > disabled in Firefox. This is the solution we used for our Chrome extension.
> > > 
> > > Is there a way that Mozilla can list this as a must have before NPAPI is
> > > disabled?
> > > How could I get involved to help implement this feature?
> > 
> > @nuancedragondev - there is js-ctypes which you can start using right away
> > in place of NPAPI. I have replaced NPAPI stuff with js-ctypes already.
> 
> I would prefer a cross-browser implementation via NativeMessaging as i think
> this will be the final way in future to communicate with native applications
> working in all modern browsers. I don't want to temporary use a Firefox
> proprietary API for this.

Ah I see, makes sense. I build for Firefox only so I didn't think of that.
Assignee: nobody → aswan
I just to add my vote to implement this before dropping NPAPI support. This is critical for my company.
Depends on: 1281995
Depends on: 1282680
Depends on: 1283010
Our company develops web browser extensions with binary part. The supported browsers are: IE, Chrome and Firefox. NativeMessaging is used for Chrome and it works flawlessly. BHO is implemented for the IE.
Before NPAPI support was dropped Firefox plugin was using it. After that we've switched to JSCtypes as there were no real alternative whatsoever.
Newly arising Microsoft Edge is going to have Chrome-like plugin architecture and support NativeMessaging. Essentially (in a perfect world) this allows us to use a single Chrome plugin for two browsers.
Addition of the NativeMessaging interface to Firefox will finally erase unnecessary obtrusive boundaries and make life much much easier for all of us developers. Please make it happen.
(In reply to g.aleksandrov.r from comment #21)
> Newly arising Microsoft Edge is going to have Chrome-like plugin
> architecture and support NativeMessaging. 

Maybe a little bit misplaced here:
Where did you find information about Microsoft Edge supporting NativeMessaging? There's nothing about that in the list of supported APIs. See here: https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/extensions/supported-apis/
(In reply to Karsten from comment #22)
> (In reply to g.aleksandrov.r from comment #21)
> > Newly arising Microsoft Edge is going to have Chrome-like plugin
> > architecture and support NativeMessaging. 
> 
> Maybe a little bit misplaced here:
> Where did you find information about Microsoft Edge supporting
> NativeMessaging? There's nothing about that in the list of supported APIs.
> See here:
> https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/
> extensions/supported-apis/

The information about this is scarce. I've being reading about it on forums and the only semi-official place I've found is https://twitter.com/shimonamit/status/571046844488245248. Still, current state of Edge's extensions is a mostly preview-like, meaning there are only a bunch of available plugins out there. If you happen to dissect any Edge plugin you will find absolutely legit  manifest.json inside and a regular background scripts. So I can safely assume that right now Edge's extensions are very like unzipped Chrome CRX files. As my theory goes, it's only a matter of time when NativeMessaging will get there.
Removing a couple of bugs that I don't think need to block considering native messaging shippable.
Open bugs about native messaging can be found with this query:

https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&status_whiteboard=native%20messaging&resolution=---
No longer depends on: 1267362, 1282680
All the dependent bugs are closed, closing the tracker too.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
:aswan do we need to update the documentation in MDN?

Checking current documentation doesn't show when will be available in FF, and according to the resolution of the bug should be in current nightly (50):

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/Runtime/connectNative

Thanks!!
Flags: needinfo?(aswan)
(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #26)
> :aswan do we need to update the documentation in MDN?
> 
> Checking current documentation doesn't show when will be available in FF,
> and according to the resolution of the bug should be in current nightly (50):

Yes, writing the actual docs is on Will's radar, he's had a lot of FF 48 related things to get cleared up first before 48 is released.  Thanks for pointing out the missing compatibility data, I created a PR for that, we ought to be able to clear that up quickly.
Flags: needinfo?(aswan)
According to the documentation at:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions

the "nativeMessaging" permission is not yet supported in the manifest file. Is this true? 

I am having an issue with my extension connecting and then disconnecting and wondering if this might be the issue.
(In reply to Dean from comment #28)
> According to the documentation at:
> 
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/
> permissions
> 
> the "nativeMessaging" permission is not yet supported in the manifest file.
> Is this true? 
> 
> I am having an issue with my extension connecting and then disconnecting and
> wondering if this might be the issue.

The manifest permissions documentation is slightly out of date, native messaging (including the permission and corresponding API functions) landed in Firefox 50 so to use it right now you need either Nightly or Developer Edition.

For questions like these, you may get a quicker answer on IRC.
(In reply to Andrew Swan [:aswan] from comment #29)
> (In reply to Dean from comment #28)
> > According to the documentation at:
> > 
> > https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/
> > permissions
> > 
> > the "nativeMessaging" permission is not yet supported in the manifest file.
> > Is this true? 
> > 
> > I am having an issue with my extension connecting and then disconnecting and
> > wondering if this might be the issue.
> 
> The manifest permissions documentation is slightly out of date, native
> messaging (including the permission and corresponding API functions) landed
> in Firefox 50 so to use it right now you need either Nightly or Developer
> Edition.
> 
> For questions like these, you may get a quicker answer on IRC.

Hey Andrew. I am trying to use NativeMessaging with Firefox but getting this error. 
No such native application com.companyName.MyApplicationName

Could you please suggest any solution for this?
'No such native application <application name>' is loged when Firefox cannot find host manifests file. Make sure you offer the config file based on the rule of 
https://wiki.mozilla.org/WebExtensions/Native_Messaging#Host_Manifests

BTW, per my testing in v50.0a2. The Host Manifests location for Linux/Global is "/usr/{lib,lib64,share}/mozilla/native-messaging-hosts/<name>.json". It's different than "/usr/{lib,lib64,share}/mozilla/NativeMessagingHosts/<name>.json" in that page, please verify.
(In reply to Beck Yang from comment #31)
> 'No such native application <application name>' is loged when Firefox cannot
> find host manifests file. Make sure you offer the config file based on the
> rule of 
> https://wiki.mozilla.org/WebExtensions/Native_Messaging#Host_Manifests
> 
> BTW, per my testing in v50.0a2. The Host Manifests location for Linux/Global
> is "/usr/{lib,lib64,share}/mozilla/native-messaging-hosts/<name>.json". It's
> different than
> "/usr/{lib,lib64,share}/mozilla/NativeMessagingHosts/<name>.json" in that
> page, please verify.

The config file is same as given in that link, but i am confused with "allowed_extensions". What value will be provided here?
(In reply to Mohammed Altaf from comment #32)
> (In reply to Beck Yang from comment #31)
> > 'No such native application <application name>' is loged when Firefox cannot
> > find host manifests file. Make sure you offer the config file based on the
> > rule of 
> > https://wiki.mozilla.org/WebExtensions/Native_Messaging#Host_Manifests
> > 
> > BTW, per my testing in v50.0a2. The Host Manifests location for Linux/Global
> > is "/usr/{lib,lib64,share}/mozilla/native-messaging-hosts/<name>.json". It's
> > different than
> > "/usr/{lib,lib64,share}/mozilla/NativeMessagingHosts/<name>.json" in that
> > page, please verify.
> 
> The config file is same as given in that link, but i am confused with
> "allowed_extensions". What value will be provided here?

I believe that name should match what is in the extension manifest.json

    "applications": {
        "gecko": {
            "id": "appname@company.com",
            "strict_min_version": "50.0"
        }
    }

which I found has to have an email syntax.

"allowed_extensions": [ "appname@company.com" ]
(In reply to Dean from comment #33)
> (In reply to Mohammed Altaf from comment #32)
> > (In reply to Beck Yang from comment #31)
> > > 'No such native application <application name>' is loged when Firefox cannot
> > > find host manifests file. Make sure you offer the config file based on the
> > > rule of 
> > > https://wiki.mozilla.org/WebExtensions/Native_Messaging#Host_Manifests
> > > 
> > > BTW, per my testing in v50.0a2. The Host Manifests location for Linux/Global
> > > is "/usr/{lib,lib64,share}/mozilla/native-messaging-hosts/<name>.json". It's
> > > different than
> > > "/usr/{lib,lib64,share}/mozilla/NativeMessagingHosts/<name>.json" in that
> > > page, please verify.
> > 
> > The config file is same as given in that link, but i am confused with
> > "allowed_extensions". What value will be provided here?
> 
> I believe that name should match what is in the extension manifest.json
> 
>     "applications": {
>         "gecko": {
>             "id": "appname@company.com",
>             "strict_min_version": "50.0"
>         }
>     }
> 
> which I found has to have an email syntax.
> 
> "allowed_extensions": [ "appname@company.com" ]

By changing all this properties also it is not working, neither in Windows nor in Linux.
Please help !! :(
It seems there is some problem in setting the Registry Setting for Windows, with Firefox Native Extension. Changing with varieties of registry settings also didn't worked for me. If any one have the correct registry settings then please share, for Windows 10 64 bit.
Under Windows 7 64 Bit I use the following registry keys for native messaging:

HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\NativeMessagingHosts\<Id of native messaging host>
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\NativeMessagingHosts\<Id of native messaging host>

I set the default value for both keys to the absolute path of the manifest file and it works here.

I'd expect settings for Windows 10 are identical.
Some details on Windows registry setting in related bug 1283010

Should only need to use the platform registry - as of 50.2 it won't check wow6432node 
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\NativeMessagingHosts\<Id of native messaging host>

or in regedit format - same on 32 or 64 bit platform
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\NativeMessagingHosts\<id here>]
@="C:\\Full\\Path\\to\\manifest.json"
Sample manifest.json for 
{
  "name": "<id here>",
  "description": "native messaging host",
  "path": "relative/path/to/nativhost.exe",
  "type": "stdio",
  "allowed_extensions": [ "your_id@here.now.com" ]
}

Calling extension might have basics of 
{
   "applications": {
      "gecko": {
         "id": "your_id@here.now.com",
         "strict_min_version": "50.0a1"
      }
   },
   "manifest_version": 2,
   "name": "__MSG_appName__",
   "permissions": [ "nativeMessaging" ],
   "version": "1.0"
}
(In reply to Mohammed Altaf from comment #34)
> (In reply to Dean from comment #33)
> > (In reply to Mohammed Altaf from comment #32)
> > > (In reply to Beck Yang from comment #31)
> > > > 'No such native application <application name>' is loged when Firefox cannot
> > > > find host manifests file. Make sure you offer the config file based on the
> > > > rule of 
> > > > https://wiki.mozilla.org/WebExtensions/Native_Messaging#Host_Manifests
> > > > 
> > > > BTW, per my testing in v50.0a2. The Host Manifests location for Linux/Global
> > > > is "/usr/{lib,lib64,share}/mozilla/native-messaging-hosts/<name>.json". It's
> > > > different than
> > > > "/usr/{lib,lib64,share}/mozilla/NativeMessagingHosts/<name>.json" in that
> > > > page, please verify.
> > > 
> > > The config file is same as given in that link, but i am confused with
> > > "allowed_extensions". What value will be provided here?
> > 
> > I believe that name should match what is in the extension manifest.json
> > 
> >     "applications": {
> >         "gecko": {
> >             "id": "appname@company.com",
> >             "strict_min_version": "50.0"
> >         }
> >     }
> > 
> > which I found has to have an email syntax.
> > 
> > "allowed_extensions": [ "appname@company.com" ]
> 
> By changing all this properties also it is not working, neither in Windows
> nor in Linux.
> Please help !! :(

Mohammed,
I did get my extension working using Firefox 50 and communicating with a native application so the implementation of this story seems to be working. You might have more luck pursuing this on a site like StackOverflow because there are other pieces to getting it to work that are outside the scope of this story. If you do open another issue post a link here. I'd like to follow it.
Yes this bug tracker is not the right forum for getting support.
Better options are one of the resources here: https://wiki.mozilla.org/WebExtensions#Communication_and_meetings
Or discourse (https://discourse.mozilla-community.org/c/add-ons/development) or stack overflow.
(In reply to Dean from comment #39)
> (In reply to Mohammed Altaf from comment #34)
> > (In reply to Dean from comment #33)
> > > (In reply to Mohammed Altaf from comment #32)
> > > > (In reply to Beck Yang from comment #31)
> > > > > 'No such native application <application name>' is loged when Firefox cannot
> > > > > find host manifests file. Make sure you offer the config file based on the
> > > > > rule of 
> > > > > https://wiki.mozilla.org/WebExtensions/Native_Messaging#Host_Manifests
> > > > > 
> > > > > BTW, per my testing in v50.0a2. The Host Manifests location for Linux/Global
> > > > > is "/usr/{lib,lib64,share}/mozilla/native-messaging-hosts/<name>.json". It's
> > > > > different than
> > > > > "/usr/{lib,lib64,share}/mozilla/NativeMessagingHosts/<name>.json" in that
> > > > > page, please verify.
> > > > 
> > > > The config file is same as given in that link, but i am confused with
> > > > "allowed_extensions". What value will be provided here?
> > > 
> > > I believe that name should match what is in the extension manifest.json
> > > 
> > >     "applications": {
> > >         "gecko": {
> > >             "id": "appname@company.com",
> > >             "strict_min_version": "50.0"
> > >         }
> > >     }
> > > 
> > > which I found has to have an email syntax.
> > > 
> > > "allowed_extensions": [ "appname@company.com" ]
> > 
> > By changing all this properties also it is not working, neither in Windows
> > nor in Linux.
> > Please help !! :(
> 
> Mohammed,
> I did get my extension working using Firefox 50 and communicating with a
> native application so the implementation of this story seems to be working.
> You might have more luck pursuing this on a site like StackOverflow because
> there are other pieces to getting it to work that are outside the scope of
> this story. If you do open another issue post a link here. I'd like to
> follow it.

Hey Dean. I have posted the question on Stackvoerflow. Kindly help me please.

http://stackoverflow.com/q/39033502/6166200?sem=2
I am the lead developer of the Web PKI extension (www.webpkiplugin.com) and I'd just like to report that this feature is working perfectly for us. We have native messaging working on Windows, Linux and Mac OS seamlessly (in fact, using the very same native host that we use for Chrome, 100% compatibility on the communication protocol as far as our extension is concerned).

Hope this makes into v50 Beta next week!

PS: I apologize if this is not the right place to report this.
Is it possible to use nativeMessaging from Android? Is that planned for the future?
It is not currently possible or planned.
Thanks @Benjamin for fast reply! Is there any alternative solution planned? I was currently using JNI.jsm - https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/JNI.jsm
There is not a plan right now, no. It would be helpful if you posted to dev-addons and talked about the use-cases wher JNI.jsm is helpful to you. Then we can decide whether there is a stable API which makes sense on Android, either JNI-based or something else. (This bug is not the place to discuss it.)
(In reply to noitidart from comment #44)
> Is it possible to use nativeMessaging from Android? Is that planned for the future?

I think this would be a bad solution because Google's native messaging scheme (now adopted by Mozilla and Microsoft), is effectively a "workaround" for desktop OSes previously depending on NPAPI/ActiveX plugins.

In Android, permissions are stored in the executable (APK), and a native messaging scheme for Android must do the same in order to be compatible with the Android ecosystem.

Android applications which need to use "Web technology" already have a very powerful solution through WebView which eliminates the need for "in-browser" extension schemes altogether.

That is, a proper native messaging solution for Android should be "liberated" from the in-browser extension scheme.  Such a system could initially build on the BROWSABLE intent filter but should long-term offer a more specific intent filter for "Web-enabled" Apps.

Related:
https://groups.google.com/d/msg/mozilla.dev.platform/1K_Uq_fx1l4/Yc93M2P2CgAJ
Is it intended that if I close the Firefox web browser all processes and sub-processes which are started by the native messaging host (E.g. our native application and all sub-processes it starts) are killed?

Even when the native messaging host launches a process which terminates directly after launching another process (the other process now has no more parent process), the parentless process will also be killed.

Google Chrome does not behave like this. Only the native messaging host started by Google Chrome is (cleanly) terminated, but the processes which have been launched by the native messaging host process survive the browser exit. The used native messaging host executable is the same as used in Firefox.


I have this behavior on Windows (tested on Windows 7 and Windows Server 2008 R2) and Mozilla Firefox 52.0.2 (32-Bit). I have not tested other combinations.

Regards,
Dominik
It is intended that the process launched from the browser is killed when Firefox exits (or when the extension is disabled).
What happens with other processes launched from that process is really up to the operating system.  There are some notes that may be useful here:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging#Closing_the_native_app

(also, commenting on a closed bug isn't a great way to get questions answered, you'll get more reliable answers on the mailing list or by opening a new bug if appropriate)
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.