9

The Chrome developer docs refer to something called Native Messaging to communicate with other desktop applications directly from the Chrome extension or app.

How can I tell when a desktop app has such native messaging available and what kind of communication it can accept? Is there a way to get the application to expose what it will communicate about?

If I needed to talk to the original developers of that desktop app, is this even the most common terminology (native messaging) so they understand what I am referring to?

Does native messaging function the same on both Windows and Mac?

Rob W
  • 341,306
  • 83
  • 791
  • 678
eComEvo
  • 11,669
  • 26
  • 89
  • 145

1 Answers1

19

An extension can only communicate with a native desktop application if that application is registered as a "native messaging host". This means that there must be some manifest file at a pre-defined, platform-specific location that declares that the application has "native messaging" capabilities and which extensions are allowed to communicate with this native messaging host.

So, by default, it is extremely unlikely that any of your desktop apps support native messaging. This term is a specific to Chrome/Chromium, and might not be understood by developers who are not familiar with Chrome/Chromium. Though every competent developer should be able to get native messaging to work after reading the documentation of native messaging.

Currently, the only supported way of communicating with native applications is through the standard input and output pipes (stdin / stdout) via a simple yet strict protocol. If the desktop app has a command-line interface, then you can easily write a proxy application that serves as a native messaging host and interacts with the desktop application. It is essentially the bridge between your Chrome extension and some other application. This proxy application can be written in any language that supports stdin/stdout, and it does not require any cooperation from the original developers of the desktop app.

The native messaging protocol is the same across all platforms, but you have to take the endianness of the system into account, and the locations of the manifest file also platform-dependent.

Rob W
  • 341,306
  • 83
  • 791
  • 678
  • 2
    TL;DR: if you didn't write the app yourself, you're probably not going to get it to work with Native Messaging. – sowbug Aug 07 '14 at 20:52
  • 4
    I am a competent developer and I could not get native messaging to work from the documentation, as it is incomplete - no discussion of how to write, configure, install the native application, no mention of gotchas that are mentioned elsewhere on the web. I got it working, but I had to find multiple other sources, and not one single source, to put it all together. – DaveWalley Nov 06 '14 at 23:08
  • @DaveWalley Could you highlight the issues you have with the documentation? I can try to get it fixed. – Rob W Nov 06 '14 at 23:16
  • 2
    No discussion of how to write, configure, install the native application, no mention of gotchas that are mentioned elsewhere on the web including manifest name must be all lower-case, and console apps will not be visible. No discussion of error conditions and messages, how to see them and what they mean. No mention that you have to take the endianness of the system into account, and how you would handle endianness in code. – DaveWalley Nov 07 '14 at 01:50
  • @DaveWalley Distributing the native app is your concern, there is no one-size-fits all. Allowed characters and error messages, follow https://crbug.com/377582. Visibility of "console apps": Of course they're not visible. Communication is handled through stdin/stdout. If you show a terminal, then the user could enter keystrokes to mess with it. If you want to show UI, spawn a new subprocess. Endianness is documented: "... 32-bit message length in native byte order." Endianness in code: Well-written code works well regardless of the endianness. Just write the 32-bit int as a 32-bit opaque char*. – Rob W Nov 07 '14 at 09:39
  • 3
    I know all of this from reading other people's work. I was responding to the statement "Though every competent developer should be able to get native messaging to work after reading the documentation". The documentation is not sufficient, you have to read other stuff, such as your comments on this page. – DaveWalley Nov 12 '14 at 18:53
  • @Rob W, An example Xcode or Visual Studio project for the app that serves as the host would be very helpful. The example extension is already there and is useful. But it would be nice to open a project and see what it means to enable communication through stdin/stdout. I'm just now realizing that that's probably why my implementation bombs on the call to connectNative(). But I haven't the foggiest on what I should to to my Mac app to make it able to respond correctly. – Alyoshak Dec 30 '14 at 19:57
  • @Alyoshak Have you already seen the Python example at https://developer.chrome.com/extensions/nativeMessaging#examples? Have you also explored the debugging section at https://developer.chrome.com/extensions/nativeMessaging#native-messaging-debugging? – Rob W Dec 30 '14 at 20:01
  • Yes to the 2nd question. That's how I found out my problem must be that I've not implemented something in the app. No, I've not looked at the Python example. I'll look at it. But since I need to implement or otherwise enable stdin/stdout communication I assumed it would avail nothing. I need to know in an Objective-C, MacOS context how to do this. But I will open the Python and see if I can glean anything. – Alyoshak Dec 30 '14 at 20:08
  • @RobW, (thanks for being responsive btw) Well there's some code for Windows, but I must somehow translate this into success for a Mac app. No msvcrt that I know of. The doc provides excellent OS-specific guidance on where to locate the manifest. Shows that the author anticipated development on different platforms. But nothing on getting the host in working order on different platforms. I think this is what Dave meant by "incomplete". I'm right at the door knocking, but can't get in yet unless I go elsewhere for info. Windows, Linux and OSX examples on the host app side would be terrific. – Alyoshak Dec 30 '14 at 20:25
  • @Alyoshak Only Windows has the silly default data-conversion stuff, you don't need that on Mac/Linux. Python is cross-platform, all you need is there. Take a look at `install-host.sh` if you want to know how to install the host on Mac/Linux. – Rob W Dec 30 '14 at 20:34
  • And, since @DaveWalley's comment about the quality of documentation, I've written a new article that explains how to develop an app that uses native messaging. The article at https://developer.chrome.com/extensions/nativeMessaging is a huge improvement over the previous one, which did mention many of the pitfalls that NMH devs may run into. If you identify any issues with the current docs, I would happily improve it again. – Rob W Dec 30 '14 at 20:37
  • @RobW, Ah, well that explains that. I haven't had very much trouble at all, and I'm sure it's bc of the updated doc. That said, I'm not even to the point of data conversion. I just built a plain-jane Mac app host and accompanying manifest and don't even know if connectNative()'s failure is unimplemented stout/stdin (or what that means yet). From the debugging section I think this is the problem: "Make sure that all output in stdout adheres to the native messaging protocol." But do not see yet how the python app "adheres to the native messaging protocol". A listener on or override for stdin?? – Alyoshak Dec 30 '14 at 20:51
  • @Alyoshak The native messaging protocol is documented here: https://developer.chrome.com/extensions/nativeMessaging#native-messaging-host-protocol. Have you already found the error messages after starting Chrome from the terminal? Perhaps you should open a new question here on Stack Overflow with your code AND error message. – Rob W Dec 30 '14 at 20:55
  • @Rob W, I just re-read (again) the section on protocol. I used it to implement calls from the background JS file. I'll open a new question with all relevant info. Thx. – Alyoshak Dec 30 '14 at 21:13
  • I haven't read the new docs completely, but it looks better. Thanks @RobW. I realize that there a many different operating systems and languages to contend with, and Google can't normally provide examples for everything in every language and OS. However, Native Messaging is an exception because it is specific to Google and has one use only. Microsoft, for example, has no incentive to provide an example for their side of the fence. If this technology is to be picked up, then Google needs to provide as many examples as possible, or help collect the works of others into one place. – DaveWalley Dec 30 '14 at 22:22
  • @RobW, I opened a new SO question. http://stackoverflow.com/questions/27712860/what-is-causing-an-error-connecting-to-native-app-when-connecting-to-a-native – Alyoshak Dec 31 '14 at 00:14