[snap] chrome-gnome-shell extension fails to detect native host connector

Bug #1741074 reported by Olivier Tilloy
This bug affects 202 people
Affects Status Importance Assigned to Milestone
KeePassXC Snap Builds
Unknown
Unknown
Mozilla Firefox
In Progress
Unknown
chromium-browser (Ubuntu)
Triaged
Medium
Unassigned
firefox (Ubuntu)
In Progress
High
Olivier Tilloy
goopg (Ubuntu)
Confirmed
Undecided
Unassigned
kdeconnect (Ubuntu)
Confirmed
Undecided
Unassigned
plasma-browser-integration (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

(initially reported at https://forum.snapcraft.io/t/chrome-gnome-shell-does-not-work-with-chromium-snap/3377)

See attached screenshot.

[Workaround]
If you're using Ubuntu 22.04 LTS, you can install GNOME Shell extensions with this app.

sudo apt install gnome-shell-extension-manager

Tags: snap
Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Olivier Tilloy (osomon) wrote :

stracing the snap reveals that /usr/bin/chrome-gnome-shell cannot be found in the context of the snap:

  15760 access("/usr/bin/chrome-gnome-shell", F_OK) = -1 ENOENT (No such file or directory)

This is not an apparmor denial. Inside the snap’s execution environment, /usr/bin is in fact /snap/core/current/usr/bin.

Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Emanuele (emanuc) wrote :

Is there any news about this bug?
To this day I still can't use plasma-browser-integration

Revision history for this message
Olivier Tilloy (osomon) wrote :

I've toyed with an unpacked example extension that talks to a native host connector (a simple python script that listens to messages and echoes all it receives).

This works with the following caveats:

 - the connector has to be installed under $SNAP_USER_DATA/.config/chromium/NativeMessagingHosts/

 - the path to the connector in the manifest needs to be an absolute path (as documented at https://developers.chrome.com/extensions/nativeMessaging), e.g.:
    "path": "/home/osomon/snap/chromium/current/.config/chromium/NativeMessagingHosts/native-messaging-example-host"

Revision history for this message
Olivier Tilloy (osomon) wrote :

chrome-gnome-shell wouldn't work like that unmodified, because the connector has external dependencies (it's a python3 script that imports GLib and Gio).

Revision history for this message
Olivier Tilloy (osomon) wrote :

Also, the connector talks to the org.gnome.Shell.Extensions D-Bus API, for which there doesn't exist a snapd interface, so one would need to be written, and I'm pretty sure it wouldn't qualify for auto-connection given the level of privilege it would expose (listing installed extensions, install and uninstall extensions).

Revision history for this message
Russ Dill (russ-dill) wrote :

This is really frustrating and 19.10 is coming up fast which I understand will switch everyone over to snap based chromium making extensions.gnome.org unusable for everyone. Any chance of switching back to non-snap based chromium if this issue isn't resolved before then?

Revision history for this message
Olivier Tilloy (osomon) wrote :

Unlikely. There are a number of higher priority issues with the chromium snap that we're focusing on now, and the plan to transition from the deb to the snap in 19.10 still holds.

I know this isn't a proper fix, merely a workaround, but you can use gnome-tweaks to manage your gnome-shell extensions.

Revision history for this message
zebul666 (zebul666) wrote :

How and why that snap has been rolled out in 19.10 while we have less feature with it ?

Note: I don't like snap.
This bug is another example why. Moreover nobody cares to fix this. If it is even possible...

Revision history for this message
Paul White (paulw2u) wrote :

zebul666, please take time to read:

https://discourse.ubuntu.com/t/intent-to-provide-chromium-as-a-snap-only/5987
https://discourse.ubuntu.com/t/please-test-chromium-snap-as-a-replacement-for-the-deb/7978
https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179

Those threads should answer your questions as to why the Chromium browser will only be provided as a snap in Ubuntu 19.10 and eventually in all supported releases of Ubuntu.

Revision history for this message
sbaragnaus (sbaragnaus) wrote :

This bug is still present in Kubuntu 19.10. Poor Chromium...

Revision history for this message
Proton Pony (protonpony) wrote :

Chromium is now incapable of managing extensions for Ubuntu's primary desktop environment? This issue is tolerable only because Google Chrome is not affected. Is Google somehow behind this apparent reluctance to remedy the problem?

Revision history for this message
Olivier Tilloy (osomon) wrote :

It's been reported that the GooPG extension doesn't work because it uses native messaging (https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179/207).

Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Coeur Noir (coeur-noir) wrote :

2020-01-06 : https://forum.ubuntu-fr.org/viewtopic.php?pid=22202596#p22202596

It seems still broken in not-yet-released ubuntu 20.04.

Revision history for this message
Avamander (avamander) wrote :

KDE Connect is also affected by this. I'm wondering though, unable to find the answer online, why was the transition to snap-based chromium made?

Revision history for this message
Efthimios Chaskaris (echaskaris) wrote :

(I think) It makes development easier, you don't have to build it for every Ubuntu version in support, or any Linux OS, it contains specific libraries you know won't cause issues with the app.

Revision history for this message
Horst Baerbel (horstbaerbel) wrote :

I want to add this affects Firefox + the KeepassXC extension too. I agree that NativeMessaging is kind of a crutch, but if there is no way to make this work safely a snap interface needs to be implemented that applications from inside / outside of snap can use. There is demand for this kind of interface, so maybe devising a "correct" way of doing this and communicating it to the application / plugin developers would be a good thing...
At the moment I work around by installing firefox from repo and ignore the issue, but some day this might not work anymore. I'm kind of worried that I upgrade to Ubuntu 20.04 and Firefox is not available from repo anymore :/

Revision history for this message
Balazs Gyurak (ba32107) wrote :

Hi! Any update on this please? This is an extremely frustrating issue that makes me consider switching from Ubuntu to something else.

Revision history for this message
Alberto Donato (ack) wrote :

This is still an issue on 20.04

Revision history for this message
Jeffrey Bouter (jbouter) wrote :

This also affects the browserpass extension for the pass (passwordstore.org) password manager

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in goopg (Ubuntu):
status: New → Confirmed
Changed in kdeconnect (Ubuntu):
status: New → Confirmed
Revision history for this message
Ian Johnson (anonymouse67) wrote :

@osomon, could you point me to an existing forum post or start a new one summarizing what accesses would be necessary to manage gnome shell extensions? I couldn't find one searching, but if there's not one we should open one to try and discuss with snapd architects. Thanks

Revision history for this message
Olivier Tilloy (osomon) wrote :

@anonymouse67: see comments #2, #5, #6 and #7 in this bug.

Revision history for this message
Farab (farabf33) wrote :

This "connector" issue is also presents on firefox snap v77.0b2 (64-bit) Ubuntu 20.04 and has not addressed yet.

Revision history for this message
Bruce Crowther (bwucie) wrote :

Harrumph: not impressed. Was working fine this morning, then an update landed me with the snap version.

Back to gnome-tweaks...

Revision history for this message
Bruce Crowther (bwucie) wrote :

Nope, never mind gnome-tweaks. Removed Chromium snap and installed Google Chrome. Problem goes away.

Revision history for this message
Marcin (mwoz123) wrote :

Any changes on this bug (since 2018)? Maybe at least workaround?

I confirm same problem on Focal 20.04 LTS with snap Opera (chrome based)

Revision history for this message
Efthimios Chaskaris (echaskaris) wrote :

Download firefox from its website, just run it from it's unzipped directory

Revision history for this message
In , Eduardo Rojas Rodríguez (edurojas) wrote :

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Steps to reproduce:

    Use the Firefox Snap build from Ubuntu Snap Store (Ubuntu software).

    Install "chrome-gnome-shell" package.

    Install Firefox GNOME Shell integration.

    Go to "extensions.gnome.org" and choose any extension.

Actual results:

Actual results:

An error report shows that says the native host connector cannot be detected.

There is no option to install the GNOME extension.

Expected results:

Expected results:

I should be able to install the chosen GNOME extension directly from the website and manage it afterwards.

The behavior is correct on the current RPM/DEB builds.

Revision history for this message
In , Release-mgmt-account-bot (release-mgmt-account-bot) wrote :

[Bugbug](https://github.com/mozilla/bugbug/) thinks this bug should belong to this component, but please revert this change in case of error.

Revision history for this message
Olivier Tilloy (osomon) wrote :

One suggestion discussed in https://forum.snapcraft.io/t/allow-classic-confinement-for-postman-agent/19228 is to use a content interface to allow third-party snaps to write to ~/snap/chromium/common/chromium/NativeMessagingHosts/. Whether it’s a good idea from a security perspective is open for discussion, and it wouldn't solve all the problems discussed here, but it could be part of the solution to enable third-party native host connectors.

Rob David (rob-david)
affects: chromium-browser → keepassxc-snap
affects: keepassxc-snap → keepassxc-browser (Ubuntu)
Rob David (rob-david)
affects: keepassxc-browser (Ubuntu) → keepassxc-snap
Revision history for this message
lerra (lerra82) wrote :

Hi team, is there any news about this 3y old bug? It would be nice to know if it is something that will be worked on or not even if the timeline indicates towards not.

Revision history for this message
udo (udopton) wrote :

Although GNOME Shell integration extension is running, native host connector is not detected. Refer documentation for instructions about installing connector.

Revision history for this message
SunBear (sunbear-c22) wrote :

For Ubuntu 20.04, I have also noticed that both snap installed Chromium and Brave Web browsers fails to work with the gnome-shell-integration extension.

In the case of Brave, this issue can be overcome by following their instruction on installing the .deb versions of brave-browser and brave-keyring files.
$ sudo apt install apt-transport-https curl
$ sudo curl -fsSLo /usr/share/keyrings/brave-browser-archive-keyring.gpg https://brave-browser-apt-release.s3.brave.com/brave-browser-archive-keyring.gpg
$ echo "deb [signed-by=/usr/share/keyrings/brave-browser-archive-keyring.gpg arch=amd64] https://brave-browser-apt-release.s3.brave.com/ stable main"|sudo tee /etc/apt/sources.list.d/brave-browser-release.list
$ sudo apt update
$ sudo apt install brave-browser

However, the chromium-browser does not have a .deb version to fix this issue. If one does issue the command:
sudo apt install chromium-browser,
this command will instead instruct snap to install chromium.

Hope the Chromium developer community can fix this issue given it was first reported in 2018-01-03. Chroumium adoption would be made easier too. Thank you.

Revision history for this message
Merlijn Sebrechts (merlijn-sebrechts) wrote :

I want to make this a bit more clear:

Every single Belgian needs this functionality in order to do basic stuff like:

* File their taxes
* Read communication from the government
* Check their medical history
* Register for a (covid) vaccine
* Rent stuff from the government
* etc.

It is vital that this issue is fixed before phasing out the Firefox deb package. With the Chromium apt package gone, there will be no alternative in the Ubuntu repositories to do these basic things in Belgium.

It’s really nice that our government is supporting Ubuntu using open-source software (https://github.com/Fedict/eid-mw) using common standards and APIs. Breaking this vital functionality looks like a big middle-finger to them.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Thanks for these useful data points Merlijn. That is certainly an important use case that we want to continue supporting. I had a quick look at both the github repository and the "Belgium eID" firefox extension (https://addons.mozilla.org/en-US/firefox/addon/belgium-eid/), and I can't find any references to nativeMessaging there. Am I missing another piece of the puzzle? Or could it be that this is a different problem altogether?

Revision history for this message
Olivier Tilloy (osomon) wrote :

And for future reference, here is Mozilla's documentation on native messaging: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging.

Revision history for this message
Olivier Tilloy (osomon) wrote :

I'm quoting James Henstridge on a possible approach to tackle the problem:

« The design of the native messaging system for extensions is something that could theoretically fit into a confinement system like snapd or flatpak. Instead of executing the native messaging server directly, the browser could ask something outside the sandbox to execute the server and hand it the communication pipes.

That's quite a large project though: it'd require modifications to the browser(s), design and implementation of an API (maybe in xdg-desktop-portal?), evaluation of the security implications, etc. »

Revision history for this message
Sebastien Bacher (seb128) wrote :

> there will be no alternative in the Ubuntu repositories to do these basic things in Belgium.

using epiphany (the GNOME browser) should work no?

Revision history for this message
Olivier Tilloy (osomon) wrote :

Discussion to figure out a solution is continuing at https://forum.snapcraft.io/t/native-messaging-support-in-strictly-confined-browser-snaps/26849. Please refrain from "me too" or "+1"-like comments (but valid use cases that weren't mentioned yet or suggestions are welcome).

Revision history for this message
In , Olivier Tilloy (osomon) wrote :
Olivier Tilloy (osomon)
Changed in firefox (Ubuntu):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Olivier Tilloy (osomon)
Changed in firefox:
status: Unknown → New
Revision history for this message
In , David D Lowe (flimm) wrote :

This bug is also being tracked at https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1741074

Ubuntu 21.10 ships the snap version of Firefox by default, (instead of the APT version), so we can expect more users to experience this bug.

Revision history for this message
Max (m-gorodok) wrote :

It seems, Belgium eID (Comment #36) uses PKCS#11, not native messaging:
https://github.com/Fedict/eid-mw/blob/master/plugins_tools/xpi/new-src/manifest.json
However the problem is essentially the same: native manifest.
Olivier filed a bug in Firefox bugzilla:
https://bugzilla.mozilla.org/1734371
"Firefox snap can't load PKCS#11 modules on the host system"

I suppose, the title of this bug does not reflect scale of the problem.
All browser add-ons that relies on native manifests are affected
in Chromium and Firefox.

I came across this issue testing an extension in Firefox using Ubuntu-21.10
live image. I am considering whether it is feasible to run a kind of thin
proxy server on host that creates a socket inside a directory mounted to snap
and runs a binary in response to connection (something like inetd).
It requires a stub for native messaging app that connects to the server
and pass through requests and responses. Generally it does not differ
too much from D-Bus and ideally requires support from Firefox for robust
checks if particular add-on is allowed to run a specific app.

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

Flatpak counterpart: bug 1621763.

Revision history for this message
In , W-jan-k (w-jan-k) wrote :

> S2 (Serious) Major functionality/product severely impaired and a satisfactory workaround does not exist

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

Proposal for a new NativeMessaging portal to address this issue: https://github.com/flatpak/xdg-desktop-portal/issues/655.

Revision history for this message
In , W-jan-k (w-jan-k) wrote :

*** Bug 1738488 has been marked as a duplicate of this bug. ***

Revision history for this message
In , David D Lowe (flimm) wrote :

This bug report is getting triaged, I'm glad. I'll add that Ubuntu 22.04 LTS is planning on removing Firefox from the APT repositories altogether and to only provide the snap version of Firefox, which is Ubuntu's default browser, so this bug is going to be experienced by a large fraction of the Ubuntu userbase at some point.

Changed in firefox:
status: New → Confirmed
Revision history for this message
In , Olivier Tilloy (osomon) wrote :

Created attachment 9267325
WIP: Bug 1661935 - [WIP] Integration with a new WebExtensions XDG desktop portal for native messaging on Linux

Changed in firefox:
status: Confirmed → In Progress
Revision history for this message
Marcos Alano (mhalano) wrote :

It seems 1Password is also affected for this bug. I don't understand what happens behind, but 1Password also fails to communicate with Firefox Snap. My original bug report: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1964546

Revision history for this message
In , Willi5m (willi5m) wrote :

Chiming in as a maintainer of an extension ([ff2mpv](https://github.com/woodruffw/ff2mpv)) that uses native messaging: users have already reported challenges getting the extension to function correctly with the `snap`-ified Firefox distribution in the upcoming Ubuntu LTS release.

Downstream tracking: https://github.com/woodruffw/ff2mpv/issues/80

Olivier Tilloy (osomon)
Changed in firefox (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
MV (mvidal) wrote :

This bug is still there with 22.04 installed this morning. As I can't install the deb package anymore this is really annoying.

Revision history for this message
Martin Zurowietz (mzur) wrote :

I can confirm that this issue is still present in Ubuntu 22.04. Extensions can only be installed manually now.

Revision history for this message
Michel-Ekimia (michel.ekimia) wrote :

[Workaround]
Use Extension manager to install gnome extensions
https://flathub.org/apps/details/com.mattjakeman.ExtensionManager

description: updated
Jeremy Bicha (jbicha)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in plasma-browser-integration (Ubuntu):
status: New → Confirmed
Revision history for this message
Proc (proc) wrote :

Same issue here with KeepassXC native transport on Ubuntu 22.04 and firefox. Worked flawless on 20.04.

Revision history for this message
Georg Jung (georgjung) wrote (last edit ):

Similar problems exist with for example expressVPN (which recommends to uninstall the snap version and install a ppa-version of firefox instead: https://www.expressvpn.com/de/support/vpn-setup/app-for-linux/#software-center) and with the video-download-helper extension (https://www.downloadhelper.net/).

Same thing: native manifest.

See also here: https://forum.snapcraft.io/t/firefox-from-ubuntu-snap-store-doesnt-support-download-helper/5663

Revision history for this message
In , Gp3033 (gp3033) wrote :

*** Bug 1763517 has been marked as a duplicate of this bug. ***

Revision history for this message
Paul Stejskal (paulstejskal) wrote :

Is this scheduled to be fixed soon? My apologies if this may not be the right bug but I use Firefox and cannot log into the Zoom app behind a SSO login (as it must go to zoom.us). Firefox already has safeguards about "are you sure you want to open this" and asks twice. It worked fine in KUbuntu 21.10 but 22.04 is broken and I cannot log in. This is a workflow stopper.

Revision history for this message
David D Lowe (flimm) wrote :

@paulstejskal I don't think the issue you are describing is caused by the bug described in this bug report. You might need to file a separate bug report or ask for help elsewhere.

Revision history for this message
Martin Zurowietz (mzur) wrote :

@paulstejskal Do you use the Zoom Snap? Please look here: https://github.com/ogra1/zoom-snap/issues/111

Revision history for this message
In , Lissyx+mozillians (lissyx+mozillians) wrote :

*** Bug 1786499 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Tommy Trussell (tommy-trussell) wrote :

I'm entering a comment here because I've not seen a tracker for the snap releases having native messaging enabled.

I've been using native messaging in FireFox to integrate with KeePassXC for several weeks now, through several FireFox beta releases (currently "beta" snap channel version 105.0b5-1). It is working as expected.

The only issue I noticed so far is each FireFox Profile needs its own separate connector to the KeePassXC database. This makes sense, but might warrant some documentation, somewhere.

Revision history for this message
In , Willi5m (willi5m) wrote :

(In reply to William Woodruff from comment #10)
> Chiming in as a maintainer of an extension ([ff2mpv](https://github.com/woodruffw/ff2mpv)) that uses native messaging: users have already reported challenges getting the extension to function correctly with the `snap`-ified Firefox distribution in the upcoming Ubuntu LTS release.
>
> Downstream tracking: https://github.com/woodruffw/ff2mpv/issues/80

Following up on this: I'm able to confirm that the extension I maintain works correctly on the "beta" channel of the Firefox snap.

However, to get it working, I had to run a manual `flatpak` command on the terminal:

```
flatpak permission-set webextensions ff2mpv snap.firefox yes
```

Is this documented somewhere? I had to dig through others' bug reports to figure out that this is what I needed, and I can imagine that a lot of other native extension users (and developers) are in a similar position.

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

As explained in [the ff2mpv issue](https://github.com/woodruffw/ff2mpv/issues/80#issuecomment-1245630280), desktop shells (such as GNOME Shell) and portal frontends (such as xdg-desktop-portal-gtk and xdg-desktop-portal-kde) should display a modal prompt the first time an extension requires this permission, and so you wouldn't need to use the flatpak command to make this choice "by hand". However minimal window managers without portal frontends (e.g. i3) are unlikely to implement that prompt, and the answer will default to "no".

Revision history for this message
DONYHP (donyjeanhp) wrote :

Still no solution for the Belgian eid card!!! There is only one way out as it is serious: Cange to Linux Mint which is withou snap or Zorin. That's what I did. What else could I do? Have a nice day all of you.

Revision history for this message
DONYHP (donyjeanhp) wrote :

Got it friends. Follow the way: Synaptic + gdebi (install) Get to the "www.myminfin.be" Download the eID-software. Back to gdebi to install the software. Then "sudo apt update" After that back to Synaptic to install them all: beid-mozilla-extension beid-mozilla- webext eid-archive eid-mw eid viewer libeidpkcs 11-0 libeidpkcs 11-bin libeidviewer 0 That's all folks.

If the driver of the eid-viewer doesn't work: "sudo systemctl enable pcscd" and then "sudo systemctl start pcscd.

Good luck! The launcher will be ready.

Revision history for this message
Lucas Sandery (lucas+-) wrote :

One can use the builds directly from Mozilla https://www.mozilla.org/firefox/all/ but the onus is on the user/sysadmin to keep it updated.

Revision history for this message
In , Olivier Tilloy (osomon) wrote :

The snap now supports native messaging through the use of [the `WebExtensions` portal](https://github.com/flatpak/xdg-desktop-portal/pull/705), which is available as a distro-patch in Ubuntu 22.04 and 22.10.

I am not closing this bug yet, because even though the patch has been cherry-picked in the snap, it hasn't landed in the tree yet.

Revision history for this message
Slalomsk8er (slalomsk8er) wrote :

Plasma Browser integration now kind of works with:

firefox 106.0.5-1 2067 latest/stable/… mozilla✓
xdg-desktop-portal 1.14.4-1ubuntu2~22.04.1

but I had to manually set permission - following directions for KeePassXC integration.

Steps:

sudo apt-get install flatpak
flatpak permission-set webextensions org.kde.plasma.browser_integration snap.firefox yes
restart firefox

@lucas+- The onus is now on the user/sysadmin as well, because of the annoying update notifications of the firefox snap and the blocking of "snap refresh firefox" by a running firefox (why do I have to do this manually).
If this would be fixed, the firefox snap will finally be worthy of inclusion into a LTS version!
IMHO, this process is what interim releases are for and I just don't get, why Canonical and Mozilla decided that they want to torture LTS users with this UX.

Revision history for this message
Lucas Sandery (lucas+-) wrote :

@slalomsk8er, I'm not disagreeing with snap's shortcomings, I'm just providing alternatives for anyone who's run into such issues. There is now also the option of getting stable builds in .deb form from the MozillaTeam (https://wiki.ubuntu.com/MozillaTeam) PPA at
https://launchpad.net/~mozillateam/+archive/ubuntu/ppa
There are many guides about how best to use it and ensure you receive automatic updates.

They have been providing ESR builds for some time, but recently added stable packages. I haven't found any info that verifies their members as employed by either Canonical or Mozilla, but they seem to have some trust by the community.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.