Yesterday, I posted documentation detailing how to move Firefox back to using a native package rather than a Snap.
Things broke as a result of a lack of support for NativeMessaging in snap, so any extension relying on this mechanism will have issues.
This, amongst other things, is something I previously experienced when Chromium was moved to
snap a couple of years ago:
Yesterday, I needed to get things up and running quickly, so looked at how to de-
snap my Firefox install.
However, if NativeMessaging support is your only concern with
snap, the good news is that help is coming.
There's an updated
xdg-desktop-portal which adds support for NativeMessaging, and the
beta version of the Firefox
snap adds support for communication with local extensions via
In this post, I'll run through the process of enabling this communication.
If you've already replaced Firefox with a
.deb you can still follow these steps to test the
snap support without overly impacting your current install.
First, you need to ensure that you've got the right version of
dpkg-query -l | grep "xdg-desktop-portal"
The version you're looking for is
1.14.4-1ubuntu2~22.04.1 (or higher, if you're reading this in the future).
If you're sporting an older version, trigger an update
sudo apt-get update sudo apt-get install xdg-desktop-portal
Install Firefox beta snap
Verify whether you already have a Firefox
snap list | grep "firefox"
If the firefox snap is already installed (i.e. if there was output above) then switch it over to the beta branch
sudo snap refresh firefox --beta
Otherwise, install a new snap
sudo snap install firefox --beta
Once that completes
xdg-desktop-portal to ensure the new version is used
systemctl --user restart xdg-desktop-portal
snap run firefox
You should get a prompt asking whether to allow Firefox to launch webextensions:
OK to approve it.
The snap should come up with your profile in place, so go to your extension and check whether it can communicate with your password manager/whatever.
In the case of KeepassXC you'll probably get
This is because the permissions aren't quite right in the container by default.
Run the following
sudo apt-get install flatpak flatpak permission-set webextensions org.keepassxc.keepassxc_browser snap.firefox yes
Then re-launch Firefox.
It should now work, and
Keepassxc will prompt you to provide an identifier for the browser.
If you're still not prompted, it may be that other extensions are interfering.
To check for this, exit firefox and then run
MOZ_LOG=NativeMessagingPortal:5 snap run firefox
Look for lines referring to KeepassXC to see whether communication is successfully being established (linebreaks added for clarity)
[Parent 45315: Main Thread]: D/NativeMessagingPortal got file descriptors for native application in session /org/freedesktop/portal/desktop/session/1_301/firefox_org_keepassxc_keepassxc_browser_1791972916: (167, 168, 169)
If that's there, look for reported failures for other extensions - on one system I found that
1Password was having issues
[Parent 45315: Main Thread]: D/NativeMessagingPortal session /org/freedesktop/portal/desktop/session/1_301/firefox_com_1password_1password_3847301527 was closed by the portal [Parent 45315: Main Thread]: D/NativeMessagingPortal cannot close session /org/freedesktop/portal/desktop/session/1_301/firefox_com_1password_1password_3847301527, unknown handle
It appears that these failures can impact the initial communication between the browser and KeepassXC.
To get KeepassXC connected
- go into the browser and temporarily disable the affected/failing extensions.
- Restart Firefox
- Attempt to connect to KeepassXC: you should now get the prompt to name the browser.
You can then re-enable the other extensions, and should find KeepassXC continues to work even after you've restarted Firefox.
Adding permissions for other extensions
If you've other extensions which aren't working, start by checking permissions:
flatpak permissions webextensions Table Object App Permissions Data webextensions org.keepassxc.keepassxc_browser snap.firefox yes 0x00
You're looking for a
yes in the permissions column.
If your extension doesn't appear (or is set to
no) you can discern the object name from the loglines you looked at above.
We ignore everything up to and including
The number at the end is a session identifier, so strip that and convert underscores (
_) to periods (
We can then set permissions with
flatpak permission-set webextensions com.1password.1password snap.firefox yes
And the extension should then be able to communicate with 1password's local agent (if it's available).
It's still frustrating that Firefox was moved to a
snap despite knowing it breaks something so fundamental as extensions. It really shouldn't be necessary to run beta releases in order to have a new LTS not break existing functionality.
But, fixes are in the pipleline.
Although clearly there are still some teething issues, they'll all fall by the wayside when the functionality crosses over from the
beta snap to
stable, (though there's some delay).
Application containerisation technologies like
snap offer process isolation, which in the long run, should lead to a more secure install, which is undoubtedly a good thing. I still have some reservations about whether something as extensible as a browser will ever be a good fit, but clearly there is at least an appetite to resolve issues.