Native Messaging Host support is fragile and not debuggable
Reported by
k...@luminance.org,
Mar 5 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Steps to reproduce the problem: 1. Register a simple native messaging host that reads a single message from stdin and writes a response 2. Send a message to the host using chrome.runtime.sendNativeMessage from an extension's background page or an extension page in a tab What is the expected behavior? The native messaging host should launch and be sent the message. When it sends a response the extension caller should get the response. What went wrong? Frequently Chrome falls over without ever returning the response to the caller. The only text that appears in the log is 'ERROR:native_message_process_host.cc(322)] Error when writing to Native Messaging host: -101'. If the messaging host is set up to exit immediately after writing its response (and flushing), you get a scenario where maybe 50% of native messaging sends work, and the others fail mysteriously with 'error when writing'. In every case, log files generated by the native messaging host show that it is receiving a well-formed message from chrome (over stdin) and writing a well-formed response before terminating normally. WebStore page: Did this work before? N/A Chrome version: Version 64.0.3282.186 (Official Build) (64-bit) Channel: stable OS Version: 10.0 Flash Version: My test case for this is a page that does sendNativeMessage in its onLoad exactly once. If I just mash F5, it successfully gets a response from the native host around half of the time, and the other half it gets "Error when communicating with the native messaging host" on the extension side. For each one of these loads, the host's log shows that it was properly sent a message by Chrome and responded, so Chrome is dropping the response on the floor. The way stdin behaves when my host is being launched by Chrome is really strange - read operations silently become non-blocking so I have to poll on stdin until there are actually bytes for me to read. (Once there are bytes I get the whole message, though, so that's fine, I guess?) Also, it seems like Chrome does not terminate native messaging hosts upon shutdown? Once it starts one it just stays running forever, and that is not the result I would expect. It also really sucks that native messaging hosts spawned by a chrome extension don't show up in Chrome's Task Manager, so they're just mysterious processes that have no obvious connection to Chrome or the extension that spawned them.
,
Mar 6 2018
kg@ - Thanks for filing the issue...!! Could you please provide a sample test file/url to test the issue from TE-end. This will help us in triaging the issue further. Thanks...!!
,
Mar 6 2018
I will try to set aside some time to build an isolated repro case. When I tried it wasn't trivial to get it to break without running a real native messaging host that does work, and for now I've simply abandoned using native messaging. From my PoV a good resolution to this bug would be for native messaging errors to have actual comprehensible log messages or documentation, since '-101' is impossible to troubleshoot.
,
Mar 6 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 7 2018
As per comment#3 from the reporter adding the Needs-Feedback label. Thanks!
,
Jun 1 2018
As there is no response/Feedback from the reporter from so long time on comment#2/3 hence closing this issue and marking it as Won't fix. @Reporter: Please feel to raise a new issue if there are any issues with chrome. Thanks! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, Mar 6 2018