1681715 - Port object with null "error" passed when Port.onDisconnect is invoked after forcible termination of native messaging host

Status: NEW

(WebExtensions :: Untriaged, defect, P5)

Description

[Dmitry]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

This is on Windows. I have an extension which uses native messaging. The native messaging host is a .NET Core console application. The extension opens a native messaging port:

  port = browser.runtime.connectNative(portName);
  port.onMessage.addListener(onMessage);
  port.onDisconnect.addListener(onPortDisconnect);

Once this code runs the native messaging host is started and runs an infinite loop processing messages. I then go to Task Manager and forcibly terminate ("end process") the native messaging host process. This is to test how a host crash is handled by the extension, not for fun. So I terminate the host process from the outside and onPortDisconnect() is invoked (as expected). It's passed the "port" object (which is explained here https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/Port). The "port" object should have "error" set to something non-null (because there was a sudden termination of the messaging host) but "error" is set to null. The extension code cannot tell whether it should reconnect the port.

In Chrome browser.runtime.lastError is set to "Native host has exited." in the same scenario.

Actual results:

onPortDisconnect() is invoked and it's passed a "port" object where "error" is set to null. The extension code sees the null "error" and decides to not reconnect.

Expected results:

onPortDisconnect() is invoked and it's passed a "port" object where "error" is set to non-null. The extension code could see that the "error" is not null and decide to reconnect.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Alex Cornestean]

Hello,

I’m attempting to reproduce the issue and it would be of great help to have the extension you’ve been using when you uncovered this bug.

Can you please attach it to this report? Thank you !

Comment 3

[Dmitry]

Hi Alex,

OpenRPA extension works just fine for reproducing this problem. The sources (specific version) are here: https://github.com/open-rpa/openrpa/tree/28ac86896207602fa46552775e82e32b3f5a571a

The proper extension is inside OpenRPA.NativeMessagingHost/addon - just ZIP it and add to Firefox.

The NMH has to be built with Visual Studio - the solution to open is OpenRPA.sln at top level, it's enough to get to OpenRPA.NativeMessagingHost and Build -> "Build OpenRPA.NativeMessagingHost", the result will be in debug\net462\OpenRPA.NativeMessagingHost.exe and the full path to that file is what you have to specify as "path" in ffmanifest.json (which is in OpenRPA.NativeMessagingHost/ffmanifest.json)

Comment 4

[Alex Cornestean]

Hello Dmitry and thank you for the additional info you provided !

Following the instructions from Comment 3 I’ve managed to build the NMH, successfully changed the path for the NMH in ffmanifest.json and packed/loaded the extension. However, maybe due to my limited knowledge regarding the specifics of NMHs, I cannot manage to reproduce the issue.

As mentioned above, I’ve managed to build the NMH. Manually running the NMH via the .exe from debug\net462\OpenRPA.NativeMessagingHost.exe results in a loop of processing messages (see the attached screenshot). Afterwards, the add-on is loaded as temporary in about:debugging and the add-on console is inspected. The add-on appears to be stuck at connecting to com.openrpa.msg. Manually terminating the NMH does nothing in the sense that the console does not display anything, but this is because, I suspect, the add-on is not connecting to the NMH.

I've attempted this process on both Firefox Release 83.0 and 84.0.

If you could provide some more detailed steps, it would be much appreciated. Thank you again !

Comment 5

[Alex Cornestean]

Attachment: 2020-12-30_12h59_05.png

Comment 6

[Rob Wu [:robwu]]

We could change the implementation to emit a non-null error message if the program exited with an error. But other than that, there is not really a good way to distinguish a terminated program from a gracefully exited program (the "Native host has exited." error is set when the stdout pipe is closed).

Regardless of the browser's implementations, if it is important to check the terminal state of the program, then you could introduce another explicit message from the Native Messaging host, to let the extension know whether it has exited "successfully".

Comment 7

[Dmitry]

Hi Alex,

You should not run the NMH .exe manually. Firefox should start the NMH when connectNative() line is executed. It looks like you haven't registered the NMH in the Windows registry.

Registering is explained here https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging - you should add HKEY_LOCAL_MACHINE\Software\Mozilla\NativeMessagingHosts\com.openrpa.msg key and set the default value to be the full path to the NMH manifest JSON file (ffmanifest.json).

Here's how it should work:

1. You make all the changes to the manifest and registry.
2. Then you load the extension.
3. Once extension is loaded the code with connectNative() runs and this causes Firefox to run the NMH executable.
4. Then you can reproduce the issure.

Comment 8

[Alex Cornestean]

Hello Dmitry,

Thank you for the clarifications!

It seems that Rob already confirmed the issue earlier, but I’ve given it a go myself nonetheless.

I’ve done exactly as you’ve instructed in Comment 7, however the add-on console outputs some results I’m not quite sure what to do about. Also the browser console reveals some info as well. I’ll attach screenshots so you can see what the issue might be.

Comment 9

[Alex Cornestean]

Attachment: 2021-01-05_10h14_37.png

Comment 10

[Alex Cornestean]

Attachment: 2021-01-05_10h14_57.png

Comment 11

[Dmitry]

Hi Alex,

The messages you see are most likely not relevant to the issue and they also indicate that the NMH executable was properly started. From there you could check whether it was actually started (the NMH process is listed by Task Manager) and then try to reproduce the issue - set a breakpoint into BaseOnPortDisconnect and then forcibly terminate the NMH process and observe how the breakpoint is hit and what gets passed as "message" parameter. "message" parameter actually refers to a "Port" object.