native messaging example: port disconnects without an error
epragalakis opened this issue · 18 comments
What information was incorrect, unhelpful, or incomplete?
the code example does not run on two different OS' and the documentation does not explain why.
What did you expect to see?
more complete and descriptive errors
Do you have any supporting links, references, or citations?
No response
Do you have anything more you want to share?
I'm trying to run this web-extension example: https://github.com/mdn/webextensions-examples/tree/main/native-messaging on Linux (latest firefox) and macOs (latest firefox dev) and on calling browser.runtime.connectNative('ping_pong'); I get a disconnect event with a null error object.
It looks like this is your first issue. Welcome! 👋 One of the project maintainers will be with you as soon as possible. We appreciate your patience. To safeguard the health of the project, please take a moment to read our code of conduct.
Came here to raise the same issue, this native messaging ping pong hello world demo is broken on Linux for me 👎
Broken on macOS Sonoma 14.5 and Firefox 128.0 as well.
After the browser.runtime.connectNative(...) call the port is immediately disconnected without an error.
The app script is not even started once.
Is this broken as in "first time I tried and it didn't work" or "was working before and now it doesn't work anymore"?
I reactivated an internal dev-plugin that I used about two years ago (https://github.com/sirthias/triggered-reload), which was working fine back then but doesn't work anymore with the latest FF.
I assumed some API changed and re-tried the native messaging example, which was my initial starting point at the time.
It was definitely working correctly two years ago.
So the problem does look like a regression to me...
Unfortunately I don't have any more info on which FF version exactly was the one that introduced the breaking change.
Ah, one more detail:
I do have the KeypassXC extension running as well, which also relies on stdio native messaging, and that one is working fine, so it's not that native messaging is broken per se.
I tried drilling into the issue to figure out what sets that addon apart from the example but had to stop due to time.
The only hunch that I currently have:
The KeypassXC extension runs an actual native binary as the target app whereas the example (and my own plugin) run (executable) scripts. Maybe sth changed in the call of the external app that now prevents scripts from running but still allows native binaries?
@sirthias
Questions:
- What Apple device are you using? (Intel or Apple sillicon)
- OS version? (macOS Sanoma 14.5 according to https://github.com/sirthias)
- Do you see any error messages in the Browser Console? https://firefox-source-docs.mozilla.org/devtools-user/browser_console/index.html
- If you launch Firefox with a new profile, do you see the same issue? For example
web-ext run -v(--verboseforwards stderr from the native messaging binary to stderr ofweb-ext).
What Apple device are you using? (Intel or Apple sillicon)
Apple Silicon
OS version? (macOS Sanoma 14.5 according to https://github.com/sirthias)
Yes, the latest Sonoma 14.5
Do you see any error messages in the Browser Console? https://firefox-source-docs.mozilla.org/devtools-user/browser_console/index.html
Nope, no errors or other clues.
As @epragalakis wrote above, the browser.runtime.connectNative(...) goes through normally but the onDisconnect event handler get's called pretty much immediately after registration, with a null error.
If you launch Firefox with a new profile, do you see the same issue? For example web-ext run -v (--verbose forwards stderr from the native messaging binary to stderr of web-ext).
Didn't know about web-ext yet, thanks for the pointer!
-v shows the verbose log output but nothing from the external script.
I don't think the external script isn't even started at all. So there is no stdout to be seen.
Do you see anything interesting when you step through the debugger while debugging Firefox yourself?
To do so:
- Open the Browser Toolbox: https://firefox-source-docs.mozilla.org/devtools-user/browser_toolbox/index.html
- Search for file NativeMessaging.sys.mjs
- Put a breakpoint at the NativeManifests.lookupManifest call at https://searchfox.org/mozilla-central/rev/f3e4b33a6122ce63bf81ae8c30cc5ac37458864b/toolkit/components/extensions/NativeMessaging.sys.mjs#71
- Activate the part of the extension that calls connectNative
- Switch back to the Browser Toolbox and step through.
If needed I am willing to have a Zoom meeting where you share your screen share to debug this issue together with you.
Thank you, @Rob--W!
With your help and a bit of drilling deeper I was able to locate the problem now.
The issue is a permissions problem.
When FF starts the external script macOS steps in to check whether the interpreter actually has the rights to access the script file, which it didn't in my case.
When I give /bin/bash Full-Disk-Access my addon starts working as expected.
Since the native messaging example runs a python script the python binary needs Full-Disk-Access as well in order to work. It's a bummer that there is no more fine-grained way to allow access only to the part of the file-system, that is actually required. At least AFAICS.
Note: Giving FF itself Full-Disk-Access is not sufficient. I guess FF starts the external binary detached from its own process tree and the external binary thus doesn't inherit FF's permissions.
In my testing I was able to get the revised native messaging demo to work as expected as long as the Python script was not located in ~/Desktop, ~/Documents, or ~/Downloads. I have not granted any applications full disk access, but Terminal does have Documents Folder and Downloads Folder access in System Settings > Privacy & Security > Files and Folders.
@sirthias, where was your native messaging host located?
My external script lives somewhere deep below ~/Documents and probably it'd suffice to simply give /bin/bash the right to access to ~/Documents, good point!
macOS Sonoma doesn't appear to offer a GUI option to manually give /bin/bash "Files and Folders" permissions, but I'm sure there is way to get this set up via the CLI. I'll look into it.
It does not work for me if I run the script from Downloads (where my terminal has access)
and neither from the home directory, which is not Desktop, Documents or Downloads as @dotproto mentioned above (my terminal does not have elevated access to this dir).
(this is on macOS sonoma 14.5 and firefox dev 129.0b2 - I havent tried it on linux)
Edit: Ill give it a go later to see if Im getting the same error and also test it on regular firefox
@epragalakis Have tried giving the python interpreter binary Full-Disk-Access, at least temporarily?
I was reporting the bug from Linux for the record