Please test your Windows Native Messaging Hosts in Chrome 113.0.5656+

[Eric Lawrence]

tl;dr: If your extension makes use of Native Messaging on Windows, please test your extension with Chrome 113.0.5656 Canary (just released) or later. If you encounter a scenario that unexpectedly changes, please let me know ASAP!

Here are the relevant bits of a longer blog post:

Native Messaging is a powerful capability for building extensions that need to interact with the rest of the system. However, over the years, users have reported a trail of bugs related to how the feature is implemented on Windows. While these bugs are typically only seen in uncommon configurations, they could break Native Messaging entirely for some users.

Some examples include:

• crbug/335558 – Ampersand in Host’s path prevents launching
• crbug/387228 – Broken if %comspec% not pointed at cmd.exe
• crbug/387233 – Broken when cmd.exe is disabled or set to RUNASADMIN

I have landed a changelist in Chromium to improve this scenario for version 113.0.5656 and later. This change means that Chrome, Edge, and other Chromium-derived browsers will now directly invoke any Native Host that is a Windows Executable (.exe) rather than going through cmd.exe instead:

Native Hosts that are not implemented by executables (e.g. Python scripts or the like) will continue to use the old codepath.

Beyond fixing the somewhat obscure bugs, this change also fixes two other bugs that were caused by the old flow and those changes could cause problems if your Windows executable was not aware of the expected behavior for Native Hosts.

In particular:
1) Chrome will now start a Native Host implemented as a Windows app (subsystem:Windows) hidden, as it is designed to do. You must explicitly call ShowWindow() if your host is supposed to be visible.

2) Chrome will now successfully kill the Native Host 2 seconds after it closes its connection to the Native Host (if Chrome is still running). This is intentional.

Edge and other Chromium-derived browsers will pick up the new behavior when their merge pumps catch up to HEAD.

Thanks for reading!

-Eric

[JohnnyCee]

Eric,

I tested (briefly) in Canary (Version 113.0.5657.0 (64-bit) under Win10) and I did not see any issues.

My Native Host is a C# console application. I did not see any issues with reading stdin or writing to stdout.

My  Native Host launches a separate executable to interact with the user when necessary. For example, the user can save data to a file on their local disk, and my Native Host app uses the prompt app to let the user specify the path via a standard Windows Save File dialog. I forget the details, but when I used the Native Host exe to open a File Save dialog, the window did not always open as the foreground window. That may have been more a C# console application issue than something Chrome was/is doing. Anyway, my prompt application uses ShowWindow and that was not affected by any change in Chrome Canary.

I did not see any issue when shutting down the browser. My log file shows an orderly shutdown where my Native Host receives a zero-length message via stdin. I write a status file and then write a "stopping" log message. That should occur in less than 2 seconds. I suppose there could be an I/O issue or some other delay that causes an issue. I will see what I can do about that.

John

[Peter Bloomfield]

This is great news. Thank you very much. The dependence on cmd.exe was causing a lot of problems for our software.

[Don Schmitt]

I'm struggling to figure out when this is expected to land in the stable channel.  If anyone on this forum groks the release cycle, I'd appreciate your help.

Eric said it would be in 113.0.5656, and the dev channel got 5668 on March 24 (and only only 5653 on March 16), so I assume this change was in the dev channel release of March 24.  If I understand the release cycle docs correctly, dev to stable  is 8 weeks?  So this change would land in stable 8 weeks from March 24, does that sound right?

Thanks!

--
Don

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/43623aa5-7bc2-445c-ab38-a3d9eb1c86b7n%40chromium.org.

[Eric Lawrence]

https://chromestatus.com/roadmap has Chrome’s release schedule.

This change landed in Chrome 113, which will reach the Stable channel in 4 weeks (Apr 26, 2023). It’s currently in the Dev Channel.

(Edge should have this change in the next Canary, and it will reach Stable the same week Chrome does).

Thanks,

-Eric

[Don Schmitt]

Thanks!  Funny, all my searching did not find that one simple status page.  This is a breaking change for us and we are trying to get our customers updated ahead of it, what is the process for pulling that change for at least another four weeks?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/47ea4980-8256-4e26-b339-93424c60c193n%40chromium.org.

[Mark Jamieson]

Breaking change. Issue 1433527: Regression in Chrome 113.X causes legacy 1Password extension to fail/grey out. Works fine in 112.X.

WebStore page: https://chrome.google.com/webstore/detail/1password-extension-deskt/aomjjhallfgjeglblehebfpbcfeobpgk

Steps to reproduce the problem:
1. Install any Chrome 113.x, 114.x, any branch
2. Install Legacy 1Password extension - https://chrome.google.com/webstore/detail/1password-extension-deskt/aomjjhallfgjeglblehebfpbcfeobpgk
3. The extension will be greyed out (fails to init due to changes in Chrome 113.x). Check the extension's error logs (can pack the extension, install it unpacked, look at the error)

Problem Description:
I have an issue on Windows 11 64-bit. Legacy 1Password extension version 4.7.5.90 (ID: aomjjhallfgjeglblehebfpbcfeobpgk) refuses to enable in Chrome 113+ (dev releases etc) - it shows as a greyed out extension, which isn't expected. This 1Password extension works perfectly fine in 112.0.5615.121 (stable), and hot-swapping Chrome binary versions proves this (no issues with other extensions or user data). Link to extension: https://chrome.google.com/webstore/detail/1password-extension-deskt/aomjjhallfgjeglblehebfpbcfeobpgk. I consider this to be a regression by Chromium team or Google. AgileBits refuses to support the legacy (Manifest v2) 1Password extension and there's no desire to store passwords remotely for a newer (but different 1Password) extension.

This legacy extension encounters issues with communication blockage for communicating with the external 1Password client app, which didn't change and functions fine.

Should see errors like these:

global.min.js:256 1Password detected a high number of disconnections from the browser extension to the main application between ...
global.min.js:105 [AGENT] Connection [object NativeMessagingConnection] disconnected.

Basically the only thing that changed was chrome binaries - hot swapped. Always worked until Chrome 113.X.

Additional Comments:
Again, legacy extension works fine in Chrome 112.X. AgileBits refuses to maintain extension. Newer (but different) extension is useless - stores passwords in cloud, and is expensive. Not yet fixed in latest Chrome 114. Why not let user decide if host exe is launched directly?

[Eric Lawrence]

Howdy, Mark-- I'm happy to take a look at this with you. Feel free to work with me off-list (ericlaw@microsoft) and we can come back with our conclusions.

I haven't been able to reproduce the problem you describe, as it fails earlier in the process. Specifically, after installing the extension (v4.7.5.90) from the web store link you've provided, and after installing the 1Password application ( https://1password.com/downloads/ ) , I find that the application has registered a NativeHost application with the identifier "com.1password.1password" but the extension is attempting to contact a (presumably randomly-generated) host with the name "2bua...com.agilebits.1password."

This obviously fails to find the installed NativeHost, so the communication fails.

In watching the error logs, I also see that the extension attempts a loopback websocket, which fails (WebSocket connection to 'ws://127.0.0.1:46365/4' failed), and tries to spawn an Application Protocol Handler, which fails (Failed to launch 'onepassword4-extension://activate/Chrome' because the scheme does not have a registered handler.).

[Mark Jamieson]

Why are you seeing nmh.rs ? 1Password 8 was implemented in Rust, 1Password 7 wasn't. Maybe you need to uninstall 1Password 8?

On Tue, Apr 18, 2023 at 6:15 AM 'Eric Lawrence' via Chromium Extensions <chromium-...@chromium.org> wrote:

Ah. In addition to requiring the outdated (and unlisted) legacy extension, this repro also requires the old version 7 build of 1Password from https://app-updates.agilebits.com/download/OPW7 . That older installer registers the random-character version of the host.

And indeed, when you look at the log, you find that the v7 client deliberately refuses the connection from the new browser:

14144  2023-04-17 23:55:23  419.326s   ERR   opw_app::managers::browser_manager:52 > failed to validate browser. Error: opw-app\src\nmh.rs:133 untrusted chromium browser

Unfortunately for this scenario, there's no easy end-user workaround because 1Password deliberately does not allow connections from unknown callers, and their logic to identify the caller is now incorrect. Based on the logs, it appears what happens is that 1Password.exe walks up the process tree, from 1Password.exe to Chrome.exe to whatever launched Chrome.exe.

If you launched Chrome from Explorer, you'll see:

14144  2023-04-18 00:00:38  740.156s   ERR   opw_app::managers::browser_manager:52 > failed to validate browser. Error: opw-app\src\nmh.rs:133 untrusted chromium browser
                                              name: explorer, publisher: Microsoft Windows, pid: 9104, session id: 1, path: C:\Windows\explorer.exe, version: 10.0.19041.2846

Whereas if you launched Chrome from the SlickRun launcher, you'll see:

 
14144  2023-04-18 00:04:39  970.081s   ERR   opw_app::managers::browser_manager:52 > failed to validate browser. Error: opw-app\src\nmh.rs:133 untrusted chromium browser
                                              name: sr, publisher: Eric Lawrence, pid: 13424, session id: 1, path: C:\Program Files\SlickRun\sr.exe, version: 4.4.9.2

While other NativeHosts requiring the old behavior could be easily accommodated (e.g. by pointing the manifest.json at a simple batch file that launches the client), 1Password cannot be fixed like this because their anti-tampering logic forbids it.

Similarly, even debugging this issue with Chromium isn't possible (e.g. by reverting the change), because the debug builds aren't signed and thus are rejected by their anti-tamper logic.

--

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/29ec7955-2f9c-4c64-bc7f-73823ea1ac02n%40chromium.org.

[Mark Jamieson]

Anyways, this change breaks 1Password, should be toggled as optional change.

[Mark Jamieson]

Eric Lawrence is on it with AgileBits. It's a nasty problem with their 1Password Chrome extensions (for 1Password 7.0, 8.0) that are breaking with the new NativeMessaging enhancement that Eric is adding to Chrome 113. AgileBits should have caught this problem long ago by proactively checking upcoming developer releases of Chrome like other companies do. Instead, AgileBits is too distracted by their subscription model profiteering and overengineering of what should have been a very simple password manager with a local vault. They also are refusing to fix their issues with their version 7.0 Chrome extension for political reasons. They baited their customers into buying a perpetual license that would knowingly become useless.

[Mark Jamieson]

Fixed. Ship.

[Rob McVey]

Hi Eric,

This change seems to have broken our native messaging setup. I was able to reproduce on Win11 / 113.0.5672.64 and have verified that our setup still works in Edge and Chrome Canary on the same device. I'm seeing "Native host exited" in our extension errors, but when I run `chrome.exe --enable-logging --v=1` the issue miraculously resolves itself (which is making it difficult to actually debug). 

Our native app is golang (using github.com/lhside/chrome-go v0.0.0-20150930231719-5fc75372b55c) and has not changed in at least a month, FWIW our app is located in "%APPDATA%\Blah Extension Helper" which contains spaces - not sure if that's relevant. Any advice for troubleshooting this further?

Thanks,

Rob

On Thursday, March 16, 2023 at 3:48:10 PM UTC-7 Eric Lawrence wrote:

[Eric Lawrence]

Hi, Rob! Do you reproduce a problem in Chrome Dev or Canary? I suspect that the specific issue you're encountering was fixed in v115.0.5736.0 and is a dupe of crbug.com/1433711

It would be VERY helpful if you could test it out and let me know.

Having said that, the entire change is getting backed out of 113 for other reasons: https://bugs.chromium.org/p/chromium/issues/detail?id=1442359#c21 and so whenever it relands it should have the 1433711 fix in with it.

[Eric Lawrence]

Ooops. Re-reading it seems you noted that it already works in Canary. So yeah, it's almost certainly 1433711. Does the app try to write to STDERR?

[Rob McVey]

Thanks for the quick reply, Eric! I will try reproducing in Chrome Dev and Canary and will post back here. Thanks for the link to the existing bug, sorry to pile on!

Rob

[Rob McVey]

I double-checked, and from what I can tell, everything is working in Canary (115.0.5751.0) but still broken in Dev (114.0.5735.9). 

Yes, there are cases where our application may right to STDERR (e.g. if the auto-update fails to apply during the request process)

[Rob McVey]

write* to STDERR lol

[Yann BR]

Hi,

In Canary, my native host fails at launch :

Extension ID : pekndhlhognicepkkfillghfjgiepojb

Error message :  Native host has exited.

The application is developed in c# and uses WinForms.

Should I be worried ? What could I do ?

[Oliver Dunk]

Hi Yann,

My understanding is that all of the relevant changes here should be reverted in the latest Canary, so it'd be surprising if you're still experiencing any issues.

Can you check for updates with the three dot menu -> Help -> About Google Chrome? If there aren't any available, your version from chrome://version/ would be great to know.

Thanks!

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/881abca3-83ef-4ead-8f03-1f11bd39cbcbn%40chromium.org.

[Yann BR]

Hi Oliver,

I checked about my version and it appears I have the latest : Version 115.0.5752.2 (Build officiel) canary (64 bits)

I added some logs by adding this parameters on the command line :

 --enable-logging=stderr --v=1 --vmodule

but I don't get more information from the logs. 

Moreover, I confirm that the executable works very well with Google Chrome Version 113.0.5672.64 (official Build) (64 bits)

it seems that the command does not reach the executable. I don't see any log in the event viewer or in my executable. How can I debug the situation at my level?

[Oliver Dunk]

Could you try in M112? This should be a Chromium release from around that time: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/1109215/

As a heads up you'll need to make sure your host is properly registered for Chromium.

Also feel free to jump in Eric if you have thoughts.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Yann BR]

Hi again Oliver,

It seems to work fine with the following version : Version 112.0.5615.0 (Build de développement) (32 bits)

So it seems that the error is related to the current most up-to-date build version. What could possibly explain this phenomenon?

Do we need to modify the code at our level to make our executable functional so that we don't see the error in production customers?

Have a nice day,

[Oliver Dunk]

So to summarise:

• It works in Chromium 112, which is the control before any of these changes.
• It works in Chrome 113, which has some changes.
• It doesn't work in Canary, where we've reverted the change and the behaviour should be the same as 112.

I don't think what you're hitting is the same issue, although it'd be nice to confirm.

The one change we made which is only in Canary is that if you send back invalid JSON from the host to the browser, we'll close the port (https://bugs.chromium.org/p/chromium/issues/detail?id=1439827). Are you sending messages from the host to the browser and is it possible any of these are invalid JSON?

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[JohnnyCee]

Checking in again to provide an update for the latest version of Canary:  115.0.5752.2 (Official Build) canary (64-bit)

I tested this version and I did not see any issues.

My Native Host is a C# console application. I did not see any issues with reading stdin or writing to stdout. My Native Host launches a separate executable to interact with the user when necessary.

John

On Friday, March 17, 2023 at 10:55:55 AM UTC-4 JohnnyCee wrote:

Eric,

I tested (briefly) in Canary (Version 113.0.5657.0 (64-bit) under Win10) and I did not see any issues.

My Native Host is a C# console application. I did not see any issues with reading stdin or writing to stdout.

My  Native Host launches a separate executable to interact with the user when necessary. For example, the user can save data to a file on their local disk, and my Native Host app uses the prompt app to let the user specify the path via a standard Windows Save File dialog. I forget the details, but when I used the Native Host exe to open a File Save dialog, the window did not always open as the foreground window. That may have been more a C# console application issue than something Chrome was/is doing. Anyway, my prompt application uses ShowWindow and that was not affected by any change in Chrome Canary.

I did not see any issue when shutting down the browser. My log file shows an orderly shutdown where my Native Host receives a zero-length message via stdin. I write a status file and then write a "stopping" log message. That should occur in less than 2 seconds. I suppose there could be an I/O issue or some other delay that causes an issue. I will see what I can do about that.

John

[Eric Lawrence]

Yann-- If you use the Chrome Developer Tools to inspect the background page or service worker in your extension that talks to the Native Host, do you see any error messages before the disconnect? For example, do you see something like "The native host sent invalid JSON; message ignored."?

Is your Native Host available for download somewhere? I'm happy to debug it for you.

thanks,

-Eric

[Yann BR]

Hi Eric, the native host is available at this address : 

https://extensions.bpce.fr/deploiement/index.html?dossier=turbosign&fichier=setup-1.0.0.70.exe

And the page to test it is available here :

https://deploiement.turbosa.banquepopulaire.fr/connecteur-chrome/interface-test/

To run the tests, go from top to bottom of the page.

You will see our extension does not have a correct behavior as of today, because our extension is at a pending review to be updated to version 3.9997. At our version 3.9996, a google tab is always opened after calling our extension (it's a known issue for us).

Thanks in advance for your help !

[Eric Lawrence]

Thanks, I'll give it a shot. I expect that we will find that this was caused by an unrelated checkin that went into Canary; that checkin is being backed out for other reasons.

(Discussion can be found in https://bugs.chromium.org/p/chromium/issues/detail?id=1442359#c38)

[Eric Lawrence]

Yann-- I confirmed that your problem was caused by the other change in 115 that was just backed out today. Your extension should work properly in tomorrow's Canary.

I explain what happened here[1] but the tl;dr summary is that Native Hosts that returned a string and then **quickly** exited would cause the new code in Chrome to drop the message (it saw that the connection had closed and stopped processing the data it had already received). That new code has now been backed out and (presumably) will not be checked back in until it corrects for this scenario.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1439827#c17

[Eric Lawrence]

The "Directly Launch Native Hosts" feature has now relanded inside Chrome Canary version 115.0.5789.0.

It’s off-by-default, behind a flag on the chrome://flags#launch-windows-native-hosts-directly page.

The equivalent change will appear in Edge in a week or so. The next step is for me to land a Group Policy that would allow admins to turn this on for users in restricted environments (Cloud PCs that forbid cmd.exe, for example).

For improved compatibility, in the re-landed version of this change that is available in Chrome Canary 115+, Chrome will now look at headers inside of the target EXE. If the executable targets SUBSYSTEM:CONSOLE, the |start_hidden| flag will be set to true. If it targets SUBSYSTEM:WINDOWS (indicating a GUI application), the start_hidden flag will NOT be set.

This compatibility accommodation will not resolve ALL problems, however. If you have a console app that occasionally shows a UI (e.g. a Windows certificate selection dialog box, for example) you will need to ensure that your app calls Show_Window explicitly.

The tracking issue for this feature is https://crbug.com/1445763.