Ah! So I went ahead of myself and moved the file into ~/snap/, which was the wrong step. Now I’ve moved it back it’s working fine, thanks!
2 Likes
if one has accidentally dismissed the initial “enable native messaging” popup… how do I enable it manually?
You can check the saved permissions with this command:
flatpak permissions webextensions
And then you can change a saved permission with e.g.:
flatpak permission-set webextensions org.keepassxc.keepassxc_browser snap.firefox yes
(replace org.keepassxc.keepassxc_browser with the name of your extension)
1 Like
Here my experience:
I had better results using systemctl --user restart xdg-desktop-portal, instead of killing the process.
On my personal computer it didn’t worked immediately. I use normally KeePassXC (Appimage) and Gnome-Shell-Integration with firefox-esr from mozteam-ppa. I installed Firefox from Snap beta channel and checked xdg-desktop-portal version.
When I installed the extension, I got a request for permission, but neither KeepassXC nor extensions.gnome.org worked in Snap-Firefox.
I could get both running with your command flatpak permission-set … snap.firefox.
With Snap-Firefox KeepassXC-extension can’t connect with Keepassxc from AppImage (2.7.1). Works with KeepassXC 2.6.1 from universe (APT/deb). AppImage-KeepassXC restarted each time I clicked on “Reload” in the extension-popup. I got a “Key exchange error”
snap list firefox:
firefox 104.0b2-1 1624 latest/beta
apt list xdg-desktop-portal:
xdg-desktop-portal/jammy-updates,now 1.14.4-1ubuntu2~22.04.1 amd64
Thanks for the feedback!
I didn’t test with KeePassXC installed as an AppImage, but I did test with the deb and the snap, and both worked. The snap has the same version as the AppImage (2.7.1), so that rules out a version mismatch problem.
Maybe the native manifest installed in ~/.mozilla/native-messaging-hosts/ didn’t point to the right binary?
1 Like
Hi,
I didn’t tried Keepassxc from Snap, because I never used the proxy-script and my intention was to exclude possible unrelated errors.
I use AppImage Keepassxc for a long time with no problems with Firefox from deb, since jammy Firefox-ESR. I downloaded yesterday Firefox as tar.gz, excluded it and test it. No problem with Keepassxc from AppImage. The manifest is correct, points to /home/keywan/.local/bin/keepassxc. I copied the AppImage to my home and tried that, but still doesn’t work.
I installed Keepassxc 2.7.1 from PPA and it worked with Firefox-Snap and Firefox-ESR. Although Keepassxc from Flathub worked without any problem with Firefox ESR or downloaded tar.gz.
Maybe it is a AppImage specific problem?!
Let me know, if I can help and should test anything.
I have both installed as snaps. I followed the instructions in the message & it appears to be working now. Thanks! -John
I can observe the problem with KeePassXC as an AppImage. Unlocking the extension launches the application if it isn’t running, but communication between the two doesn’t seem to be happening.
The obvious difference between running it as an AppImage and installing it as a deb/snap is that there’s only one single executable for the AppImage, whereas the deb/snap install a proxy executable that’s used for communication with the extension. And sure enough, when I unpacked the KeePassXC AppImage I found that script called AppRun.wrapped:
#!/usr/bin/env bash
export PATH="$(dirname $0)/usr/bin:${PATH}"
export LD_LIBRARY_PATH="$(dirname $0)/usr/lib:${LD_LIBRARY_PATH}"
if [ "$1" == "cli" ]; then
shift
exec keepassxc-cli "$@"
elif [ "$1" == "proxy" ]; then
shift
exec keepassxc-proxy "$@"
elif [ -v CHROME_WRAPPER ] || [ -v MOZ_LAUNCHED_CHILD ]; then
exec keepassxc-proxy "$@"
else
exec keepassxc "$@"
fi
In the case of firefox, the launcher expects $MOZ_LAUNCHED_CHILD to be set in order to execute the proxy binary. But given that the portal is handling this (not Firefox directly), that environment variable is not set, and as a consequence the GUI app is launched instead of the proxy.
I tested adding the proxy parameter to the path in the native messaging manifest (~/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json), but it wasn’t taken into account. The specification for native messaging manifests doesn’t say anything about parameters, only that the path must be absolute on Linux. So I guess any additional parameters are simply ignored.
I then tested a different approach to work around this limitation: I created a wrapper script in ~/bin/kpxc-proxy:
#!/bin/sh
exec /home/ubuntu/KeePassXC-2.7.1-x86_64.AppImage proxy
and I modified the native messaging manifest’s path value to point to that wrapper (absolute path, of course). And voilà, communication between the Firefox snap and the KeePassXC AppImage works.
Not entirely straightforward, but at least there is way around that limitation.
3 Likes
Trying this out with my Open_with extension.
https://addons.mozilla.org/en-US/firefox/addon/open-with-anything/
It’s a simple versatile python script, it passes a messaged URL to a native program with subprocess (chromium, opera, wget , mpv, gimp etc) but that last part doesn’t seem to work anymore.
....
subprocess.run(["snap", "run", "opera", url])
....
Permission denied: 'snap'
...
subprocess.run(["/usr/bin/wget", url])
....
No such file or directory: '/usr/bin/wget"
How is it supposed to work?
UPDATE, it seems to work in Firefox Beta, it’s working partly in Firefox stable. Script is recognized, but pograms can’t be run.
1 Like
It’s working for me here, after I modified the manifest so that the path is absolute (per specification, i.e. I changed ~/bin/browser/open_with.py to /home/osomon/bin/browser/open_with.py.
I’m observing that when delegating to wget, files are downloaded to /home/osomon/~/Downloads, i.e. there’s an extra folder named ~ that’s created under my home, instead of using the default XDG download directory.
1 Like
Thx for trying out.
Does it work in Firefox stable also?
IMHO the release (and forced Firefox update to snap) of Ubuntu 22.04.1 LTS should not break native messaging in the default browser.
(and thank you for your comments, it’s a simple extension for advanced users, it lacks an install script, so sure it needs tweaking of the path in the manifest for an absolute path, also wget is used as an example, guess most power users know about a ~/.wgetrc conf file to set the dir, or using a wget intermediate helper script)
It’s not working in firefox stable yet. We narrowly missed the release of 22.04.1, it’s unfortunate, but we hope for the feature to go into stable very soon.
2 Likes
That’s a pity indeed.
Guess it’s a lot of work. Looking fine in the near future.
Bit off-topic, what about support in Flatpak and/or Chromium?
well, luckily snaps turn apps into rolling-release applications so you will very soon get all the fixes 
3 Likes
Once this lands in upstream firefox, the flatpak will benefit from it, on distributions where the WebExtensions portal is available (currently only Ubuntu >= 22.04).
Chromium will require similar integration work.
1 Like
I can’t get it to work :
# snap list | grep firefox
firefox 104.0b9-1 1689 latest/beta mozilla** -
# dpkg -l | grep xdg-desktop
ii xdg-desktop-portal 1.14.4-1ubuntu2~22.04.1 amd64 desktop integration portal for Flatpak and Snap
ii xdg-desktop-portal-gnome 42.0.1-1ubuntu2 amd64 GNOME portal backend for xdg-desktop-portal
ii xdg-desktop-portal-gtk 1.14.0-1build1 amd64 GTK+/GNOME portal backend for xdg-desktop-portal
[Parent 37202: Main Thread]: D/NativeMessagingPortal will be used
[Parent 37202: Main Thread]: D/NativeMessagingPortal is available
[Parent 37202: Main Thread]: D/NativeMessagingPortal creating session with handle suffix firefox_org_gnome_chrome_gnome_shell_1223787496
[Parent 37202: Main Thread]: D/NativeMessagingPortal session created with handle /org/freedesktop/portal/desktop/session/1_139/firefox_org_gnome_chrome_gnome_shell_1223787496
[Parent 37202: Main Thread]: D/NativeMessagingPortal starting org.gnome.chrome_gnome_shell, requested by chrome-gnome-shell@gnome.org in session /org/freedesktop/portal/desktop/session/1_139/firefox_org_gnome_chrome_gnome_shell_1223787496
[Parent 37202: Main Thread]: D/NativeMessagingPortal native application start requested in session /org/freedesktop/portal/desktop/session/1_139/firefox_org_gnome_chrome_gnome_shell_1223787496, pending response for /org/freedesktop/portal/desktop/request/1_139/firefox/1121656702
[Parent 37202: Main Thread]: D/NativeMessagingPortal got response signal for /org/freedesktop/portal/desktop/request/1_139/firefox/1121656702 in session /org/freedesktop/portal/desktop/session/1_139/firefox_org_gnome_chrome_gnome_shell_1223787496
[Parent 37202: Main Thread]: D/NativeMessagingPortal native application start canceled by user in session /org/freedesktop/portal/desktop/session/1_139/firefox_org_gnome_chrome_gnome_shell_1223787496
[Parent 37202: Main Thread]: D/NativeMessagingPortal session /org/freedesktop/portal/desktop/session/1_139/firefox_org_gnome_chrome_gnome_shell_1223787496 was closed by the portal
[Parent 37202: Main Thread]: D/NativeMessagingPortal cannot close session /org/freedesktop/portal/desktop/session/1_139/firefox_org_gnome_chrome_gnome_shell_1223787496, unknown handle
Try the following command:
flatpak permission-set webextensions org.gnome.chrome_gnome_shell snap.firefox yes
(this requires flatpak to be installed)
1 Like
Doesn’t work here in 104 stable, released yesterday.
Any idea when it will it ship?
Still left in the dark.
Is native messaging now supposed to work in Firefox Snap stable 104+?
Why isn’t there any reference in changelog or known issues list.