I have a desktop application for which I wanna create a chrome extension. I just need to know if I can access windows COM objects from a chrome extension.
No, you cannot (directly).
If you need that, you'll need to create some native application "proxy" that will talk to your extension over Native Messaging protocol, and talk to your existing application via whatever native method you want (e.g. COM).
Note that this Native Host application cannot be bundled with the extension in Web Store; but you could bundle it with your desktop application.
Related
I'm trying to determine if I can access any browser api for chrome OS that will allow me to identify the device that its running on when the application has been force-installed in kiosk mode as a PWA.
We're running into exactly the same issue right now. The correct path seems to be to create a PWA and to connect it to a (pre-installed) extension that has access to the enterprise.deviceAttributes:
See https://developers.chrome.com/apps/migration:
"If there is a capability that your Chrome App has that the regular web platform can't provide, it might be available as an extension API. In this case, you use a progressive web app together with an externally connectable extension your web app can send messages to."
enterprise.deviceAttributes are only accessible if the calling App/Site is pre-installed to the device and not loaded dynamically, so it cannot run in the PWA by design.
But with this tutorial, it seems possible:
https://developer.chrome.com/extensions/messaging#external-webpage
We're looking into that right now and will post our progess here.
i want to know if it is possible for google chrome extension to check if there is already a native app installed on the client machine or not
So we established that you control both the extension and the native app.
Note that the extension cannot access the filesystem to check for existence of files; presumably, you also want to detect the presence of the app even if it's not running, and ideally be able to launch it if it isn't.
The best way to check that the app is installed is to provide a Native Messaging host in the app. The installer would then add a registry key to let Chrome know that the native host is present, and you can connect to it.
Now, there are some considerations:
You can't check the presence of the native host without trying to launch it.
The process launched that way lives only as long as its communication port is opened in the extension.
The communication channel between the extension and the app is the STDIO.
It would not be wise to just declare your main Windows Forms app as the native host. You should write a separate utility app that can communicate according to the Native Messaging protocol (even if to just answer "I'm here"). If needed, it can launch the main app and/or communicate with it as needed using other channels. You could also just launch the main app from your native host and then communicate with it using WebSockets.
I am developing chrome extension which needs to communicate with my running service. I tried to use Chrome Native messaging, but I didn't manage to make the extension communicate with running service.
I did manage to communicate with native (not already running app), as described here:
Google chrome native messaging
It's impossible for Native Messaging to "connect" to an already-running process.
Therefore, you have to either use something else (a local WebSockets server in your service is a good alternative idea) or make the Native Messaging host be some sort of "proxy": you can start a new one from Chrome, and it uses some other channel to communicate with the already-running service.
1password's chrome extension checks to see if the app is installed on your desktop before you can actually do anything.
I was wondering on how could I implement something similar?
This is probably implemented using the Native Messaging API.
Alternatively, the app can simply have a web server / websockets server open on the local machine, but it would mean the connection will only work while the app is running.
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?
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.