Whitelisted allowedURLschemes breaks some desktop apps

The whitelist exists because it acts as a mediation layer where we can at least review the application interpreting the input from the snap world. It is true that this is an inconvenience but the _current_ plan is to keep the whitelist in place and expand it on a case-by-case.

This causes a significant annoyance in the Snap-based Chromium (from Ubuntu 19.10).

There should be a way to a) ignore that whitelist or b) make it extendable by the user. Having that hard-coded in code makes no sense.

Is there an upstream task / bug report for this I can track?

As a result, upgrade Ubuntu to 19.10 broke all our intranet apps/workflow which heavily based on web based portal with a lot of ssh:// links used to quickly open terminal to many thousands managed linux servers and tg:// links to arrange telegram channels related to tasks.

There many hundreds custom URL schemes used by different enterprises around the world, I have no idea how whitelist approach might work at all.

From the 4 duplicate bug reports so far, here is a list of custom schemes that have been reported not to work in the chromium snap:

 - steam
 - apt
 - ssh
 - tg
 - magnet

@Zygmunt: I'm happy to submit a pull request to add those to the whitelist, are they all ok or do you have concerns about some of them?

i'd like to notice that since ubuntu 19.10 chromium is available only as a snap, thus this bug makes it impossible for chromium users to open non-http links in fresh ubuntu from inside browser they've chosen :(
(the workaround is to copy a link and open it elsewhere, e.g. in firefox)

@osomon there us also "spotify" protocol handler: https://developer.spotify.com/documentation/general/guides/content-linking-guide/

People were also mentioning "irc" and "git" above.

Here is a pull request to add "apt" to the whitelist, which hopefully should be pretty uncontroversial security-wise: https://github.com/snapcore/snapd/pull/7731

From duplicate bug #1853008, another custom scheme: zoommtg

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

From another report on the snapcraft forum, another custom scheme: urn

(https://forum.snapcraft.io/t/chromium-user-open-error-supplied-url-scheme-is-not-allowed/15429)

Sorry for the +1 comment here, but can we revisit the severity of this? 20.04 is coming and it's a notable feature regression for chromium-browser.

I really like this idea for fixing it: https://github.com/snapcore/snapd/pull/7731#issuecomment-585721100

Hi! This bug also affects me. Magnet torrent links don't work at all. Could we have an update on this please?

Wow. This is all remarkably chill for a bug that boils down to "Chrome can't launch external apps". I just started a new job and I'm trying to set up ubuntu 19.10 as my primary desktop and I'm being blocked by this. Both slack and zoom fail to launch because of this. It also means that apps that want to use Google to authenticate, and thus launch chrome to run the google login and then get a URL callback don't work (Slack in particular).

Agreed. This seems like fundamental desktop functionality to me.

My approach so far is to right click on the link, copy it, and then in a terminal type

xdg-open "<paste>"

where <paste> is the pasted link.

In case it's useful, here's an updated list from above, but clearly there should be a way for people to choose themselves what to whitelist. Can someone explain how to add to the whitelist?

 - steam
 - apt
 - ssh
 - tg
 - magnet
 - urn
 - zoommtg
 - irc
 - git
 - tg

As I said earlier I totally agree with the comment above :

Manual whitelisting from the snap team will always be a blocker for such a widely adopted use of an important browser.

That will push people to use chrome which IMO a failure on the libre software side.

This is personally impacting my ability to use Chromium to run the F5 SSL VPN, which uses the f5-epi and f5-vpn schemes.

There needs to be a way for individual users to add to the whitelist. Adding more schemes like "apt" is just making the issue less painful.

Zoom.us meeting links (zoomus://) are not launching the app anymore. This reduces drastically the productivity, since I have to manually copy the meeting ID into the Zoom app. Multiply that with about 10 meetings a day and it results in moving to Firefox.

@zyga Why this isn't a high pro bug? Many application uses xdg-open to it's login function. I couldn't login e.g in : Slack, Intellij-toolbox so this is instantly breaking the ability to use this snap in a work environment.

How I managed to work around this to add a new Slack workspace:

* Click the + button in the desktop app. This opens https://app.slack.com/ssb/add?… in Chromium.
* Press F12 to get the Network tab. Make sure *Preserve Log* is checked.
* Type in the workspace URL and hit Enter.
* When prompted to run `xdg-open`, accept it. Nothing will happen.
* Look in the request *Name* column for the red request starting with `slack://` in the full URL displayed in the hover tip.
* Right-click to *Copy » Copy link address*.
* From a terminal window, type `xdg-open `, paste the link, and Enter

For Zoom it is usually less cumbersome since you can just open the Zoom app manually and copy and paste the meeting ID from the URL displayed in the browser, though this does not seem to work in all cases.

i'm sure an easier workaround is to (temporarily) use firefox for this. i use this one when i need to open some tg:// links in telegram app

Please add the vmrc URL scheme, needed by VMWare ESXi. Thanks.

any updates on this, manual url interception and copy pasting is getting old :(

Hate to be another +1 but, any updates on this. This is quite a major issue for real world use right now.

Yeah, this can be labelled a COVID-relevant bug, since there are countless new users flooding to Zoom, etc...

It looks like this is being worked on within the last four days:

https://github.com/snapcore/snapd/pull/8304

But only for zoom?!

And I'm not sure of the nature of the fix or who would get it.

This may reflect the latest inclusions (see line 95 or so) ? It shows "apt" being included:

https://github.com/snapcore/snapd/blob/master/tests/main/xdg-open/task.yaml

If the approach so far is to individually whitelist classes of links, surely can't this be better dealt with by doing something similar to how Chromium responds to me clicking on a downloaded file: it asks me if it's okay to have snap launch that file? Can't we do this for links that go to xdg-open without downloading a file?

I agree @cpbl -- there are almost certainly better options available. Maciej Borzecki detailed a good proposal at https://github.com/snapcore/snapd/pull/7731#issuecomment-585721100 (with some follow-on thoughts added by jdstrand at https://github.com/snapcore/snapd/pull/7731#pullrequestreview-362900171), but at this point it's up to someone to implement it.

I just did the easy/lazy small Zoom PR, since I'm just an internet rando without time at the moment to develop the real fix.

Unless something dramatically changes here in the next couple of weeks, I think anyone wanting a simple way to get the old xdg behavior on 20.04 is going to forced to:

1) Use Google-supplied binary Chrome
or
2) Switch distros

Can anyone help with a workaround suggestion while we're waiting for this to get fixed?

I normally manually patch package issues like this, but for some reason it doesn't seem to be working in this case:

```
TMPDIR=$(mktemp -d)
cd $TMPDIR
apt-get -y source snapd
sed -i 's/"http", "https", "mailto", "snap", "help"/"http", "https", "mailto", "snap", "help", "apt", "zoommtg", "slack"/' snapd-2.42.1+19.10/usersession/userd/launcher.go
cd snapd-2.42.1+19.10 && dch -l$(hostname) fix_missing_app_types
cd ..
cd snapd-2.42.1+19.10$(hostname)1 && DEB_BUILD_OPTIONS=nocheck debuild -b -uc -us
cd ..
sudo dpkg -i snapd_2.42.1+19.10$(hostname)1_amd64.deb
```

It seems to be updating /usr/bin/snap properly, but the xdg-open is still blocked.

Also affecting Slack. Not possible to login to Slack app and I needed to switch to Firefox for now.

Okay, after having manually copied and dissected a Zoom URL for the Xth time I finally got annoyed.

I've updated the instructions from comment #27, here's a possible work-around by rebuilding the snapd sources:

```
apt-get build-dep snapd
TMPDIR=$(mktemp -d)
cd $TMPDIR
apt-get -y source snapd
sed -i 's/"http", "https", "mailto", "snap", "help"/"http", "https", "mailto", "snap", "help", "apt", "zoommtg", "slack"/' snapd-*/usersession/userd/launcher.go
cd snapd-* && dch -l$(hostname) fix_missing_app_types
cd ..
cd snapd-* && DEB_BUILD_OPTIONS=nocheck debuild -b -uc -us
cd ..
sudo dpkg -i snapd_*.deb
sudo service snapd restart
killall snap
```

Restart the client app. After that opening Zoom URLs in Chromium just works for me. What a relief.

For some reason I unable to rebuild snapd following #29 instruction. All goes fine, but in the end xdg-open wont work. I've checked /var/log/syslog and it full of:

chromium_chromium.desktop[1674]: user-open error: Supplied URL scheme "magnet" is not allowed

What is interesting, when I'm changing the source code of launcher.go I also changed the line with error text to "Supplied !!! URL scheme"... but in syslog error line still appears the same with out "!!!" this conclude changes never goes into the /usr/bin/snap binary file.

I tried to remove ~/.cache/go-build /tmp/go-build turn off wifi, but still resulting package still produce old version of error text. I have no idea how to rebuild package correctly, following #28 not working.

Seems like a new linux virus preventing me from running compiled snap. Not the right place to report but who knows? When I recompile the snap package and changed "help" output to "refresh !!! and remove snaps" and unpack the content of resulting file into 123/. I reinstall the system package and result md5 sum look like this:

axet@axet-laptop:~/local$ md5sum 123/usr/bin/snap /usr/bin/snap
f6639f5060dcd23506082f6ff0699f72 123/usr/bin/snap
f6639f5060dcd23506082f6ff0699f72 /usr/bin/snap
axet@axet-laptop:~/local$

When I run the package from ./123/usr/bin/snap I got my "!!! and remove snaps" but when I ran the same file (same md5) from /usr/bin/snap I got the old output.

axet@axet-laptop:~/local$ ./123/usr/bin/snap
The snap command lets you install, configure, refresh !!! and remove snaps.
Snaps are packages that work across many different Linux distributions,
enabling secure delivery and operation of the latest apps and utilities.

...

axet@axet-laptop:~/local$ /usr/bin/snap
The snap command lets you install, configure, refresh and remove snaps.
Snaps are packages that work across many different Linux distributions,
enabling secure delivery and operation of the latest apps and utilities.

...

Even when I copy my /usr/bin/snap into 111111 file and run it from another location I still getting my new "!!! and remove" string. Seems like somthing (bug or virus) load old snap package when I run it from /usr/bin/snap location and when I read the same file I get my actual file system data. Not sure what kind of virus, trojan or system nvme, encryption or kernel bug I have... Maybe anyone knows?

Alexey I'm having the same experience as you. It's uncanny, feels like something obvious is missing. Not sure how it's working for Kevin above.

I just found the issue second ago. It is related to SNAP_REEXEC behavior. The idea is to run snap from snap_core installed from snap. If you have system snap installed it will be reexec'd from snap core. To disable it you need to change the source.

Just run this before compilation and you will be ok:

sed -i 's/!osutil.GetenvBool(reExecKey, true)/true/' snapd-*/cmd/cmd_linux.go

wow, @kfunk and @axet, thank you so much for this effort!

Alas, I get stuck at the very first step:

sudo apt-get build-dep snapd
Reading package lists... Done
E: You must put some 'source' URIs in your sources.list

@cpbl see https://askubuntu.com/a/158872 ("Software & Updates" in the menu now)

To @kfunk @axet @troyready: That worked perfectly for me. Thank you so much!!!

For those like me for whom these are all magical incantations, here's my sequence aggregated from advice above:

Press the Ubuntu/Super key and type "Software" and pick the one that is called "Software & Updates". On the first tab, make sure "source code" is checked. Then, open a terminal and paste the following (line by line up to the apt line, then the rest can go together):

```
apt-get build-dep snapd
TMPDIR=$(mktemp -d)
cd $TMPDIR
apt-get -y source snapd
sed -i 's/"http", "https", "mailto", "snap", "help"/"http", "https", "mailto", "snap", "help", "apt", "zoommtg", "slack"/' snapd-*/usersession/userd/launcher.go
sed -i 's/!osutil.GetenvBool(reExecKey, true)/true/' snapd-*/cmd/cmd_linux.go
cd snapd-* && dch -l$(hostname) fix_missing_app_types
cd ..
cd snapd-* && DEB_BUILD_OPTIONS=nocheck debuild -b -uc -us
cd ..
sudo dpkg -i snapd_*.deb
sudo service snapd restart
killall snap
```

This also affects the scheme "jetbrains", it would be nice to login to my JetBrains Toolbox again via Chromium

And then people are surprised why Linux community is no negative to Snap.

Contributing to the discussion with rudeness is not conductive to collaboration, and will be moderated.

We do take the fact that people are recompiling snapd because of this as a signal that we need to think whether there are possible ways we can improve the situation.

FYI, in recent PR discussions[1] we've acknowledged that we should make it easier to allow different URL schemes into snapd and I laid out some criteria/process ideas on how to make this happen, and I applied that criteria to the zoommtg PR and it was merged quickly. I discussed with Samuele that we could make this go even faster if we codify things for reviewers as well as some other implementation details.

In short, today, the snapd team is in a position to be more responsive with adding new url schemes and we'll make it so we can go even faster.

For people who want snapd to support new URL schemes I suggest doing one of:

* if you are able, submitting a PR to snapd[2] for the URL schemes you are interested in
* filing a new bug[3] for the requested url scheme (eg, "add support for url scheme ...") and then someone can take a look

Thanks

[1]https://github.com/snapcore/snapd/pull/7731#pullrequestreview-362900171
[2]https://github.com/snapcore/snapd
[3]https://bugs.launchpad.net/snapd/+filebug

With respect, I think focusing on an improved response time for the PRs is missing the forest for the trees.

The vast majority of users that experience these bugs won't be the ones to make Ubuntu SSO & GitHub accounts and contribute PRs to fix it. They're just going to get a silent launch failure, and tell their social circles about how Ubuntu doesn't work. For snap's long term success, there needs to be a stronger focus on a good user experience or we're just going to lose users.

The only reason we don't see more of the errors now is that the default browser (Firefox) isn't shipped as a snap, and I really don't like being happy about that.

Fundamentally I think there needs to be a bigger focus on a user-friendly solution, something like the proposal to make all system registered apps work by default, or anything else like that.

In short, the best way to improve the situaition is sudo apt purge snapd.

Does snapd solve any user's problem? No one. Does it break usual apps behavior? Absolutely, as in this case.

Why I should to PR for repairing things that works perfectly for years in any desktop behavior before you came? Did you forget to take your meds?

Seriously guys, I mean why the heck would you replace something that works like a charm (normal apt, .deb files or PPAs) with something that's still obviously not ready to be thrown at people's machines forcing them to use snaps instead of regular .deb. you don't even leave the user the choice of doing otherwise. Shame on the Open Source community for choosing to adopt such methods. Plus the themes on snaps are broken as well. Like the mouse cursor is white by default for my system, but inside most of snap apps it turns smaller and black too. Why? Cause snap is still to this day a pretty broken and inconsistent POS.

Is there a way to get a snapd package with the merged PR for zoommtg:// without recompiling from source?

This bug also affects me on a fresh 20.04 install ...

To Jacob: You can just copy the link, by right clicking the "join meeting" button, then open a terminal and type
$ xdg-open "zoommtg://...[your meeting link]..."

@Gilyen: Yes, of course -- or open the link in Firefox. But that gets really annoying after a while. I was hoping for a snap package that fixes this without me having to build from source. Because if I'm going to go that far, I'll just remove the damh hard-coded whitelist completely. It's one of the most horrible ideas I've seen in a long time.

(I just wrote an article about this issue. Feel free to comment before I publish it.)

# Ubutu 20.04 was just released and is broken right from the start (as is 19.10)

Millions of people have started working from home and may have even done a fresh install of Ubuntu 20.04, but as they use Chromium (the pre-installed open source version of the Google Chrome browser) and want to join an online video conference with zoom .. it does not work! Joining slack from a link ... does not work! What's going on ???

TDLR : The team responsible for the snap (Snappy) software manager at Ubuntu messed it up. They do not understand the implications and severity of this bug since almost 2 years, and there is no easy fix at the moment.

Your options:
1) Use Firefox instead of Chromium browser, although Firefox (still) has (sometimes ?) an issue with opening a zoom link. When prompted to run `xdg-open` it does not work the first time, you have to do it a 2nd time, (only) then it works.

# Background story (skip if you are not interested):

Working in IT for many years, I have praised Ubuntu as a free, stable, non-intrusive, great alternative to Windows in recent years, which (now) works out of the box on most hardware. I regarded it now as a great replacement (even from a usability point of view) for the average (non technical) user.
My partner is a totally (!) non-technical person, working as an online language teacher for her living, but I was able to convince her to get rid of Windows just after she bought a new laptop and let me replace it with Ubuntu 18.04 MATE.
Everything worked fine, which is good because otherwise she would blame me that she looses her income because I replaced Windows with Ubuntu. It's also good me for, as every hour I have to spend on administrating her computer is one paid hour less on my side.

A few months ago, I upgraded to 19.04, which is not supported with new updates any more, so now that Ubuntu 20.04 came out on 24 April 2020, I thought it would be a good idea to anyhow wipe the whole setup and do a fresh install of Ubuntu 20.04 MATE.

# END - Background story

# The problem : Ubuntu 19.10 & 20.04 + Chromium + zoom, Telegram, slack ... (many desktop apps)

Starting with a fresh install of Ubuntu 20.04 MATE, suddenly it was not possible any more to launch zoom from the online learning platform, and for the heck I could not get it to work quickly (had to give my Arch Linux / Manjaro Laptop to my partner so that she could in time conduct her online teaching).

Some google research surfaced the following facts which I will try to summarize here :

* Since Ubuntu 19.10, Chromium is installed by default using the snap (Snappy) package management system [https://snapcraft.io] [https://en.wikipedia.org/wiki/Snappy_(package_manager)]

* For some reason ("security" ? - to be filled in)
"snapd has a hard-coded list of allowed URL schemes. Currently that is limited to "http", "https", "mailto", "snap".
which break a lot of desktop apps, not limited to zoom, but also many other important widely used ones as well (Telegram, github, slack, ... looks like "every polular app")

This bug has already been reported 2018-06-14 !
[https://bugs.la...

Hi Sven Meyer,

I'd like to address one bit of your article:

"... and I do not understand the reaction - Samuele Pedroni (pedronis) wrote on 2020-04-23: "Contributing to the discussion with rudeness is not conductive to collaboration, and will be moderated.""

The reason for Samuele's comment was that there was a user in this thread who posted a comment full of swearing (with the F-word) in a non-constructive way. That comment was removed rather quickly, so I believe not many people saw it. Samuele's comment on its own indeed can be confusing. I fully agree with him that rudeness is not the way to go.

For the record, I am also a frustrated Ubuntu user who suffers from the same bug, but I felt it important to point this out, to be fair to both sides. I fully agree with your article otherwise, but IMO it might be better to leave out this part.

Sven, allow me to contribute a few corrections/clarifications to your article:

« but as they use Chromium (the pre-installed open source version of the Google Chrome browser) »

This is incorrect, chromium is not pre-installed. One has to go and install it from the package manager/software store.

« ... and I do not understand the reaction - Samuele Pedroni (pedronis) wrote on 2020-04-23: "Contributing to the discussion with rudeness is not conductive to collaboration, and will be moderated." »

Samuele referred to a comment that contained offensive language (thus violating the Ubuntu Code of Conduct) that was removed to keep the conversation civil.

« $ snap remove chromium
$ sudo apt install chromium-browser »

Not every piece of advice on the internet should be followed blindly. The chromium-browser deb package is now a transitional package that installs the snap, so the above will obviously be a no-op. There are details about why this was done at https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition.

Seeing that this bug got considerable attention, I'd like to highlight another bug that is even more serious (in my opinion) which relates to Chromium being snap:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074

This other bug affects more people, breaks numerous apps (including Gnome's own extension site!) and there is absolutely no workaround for it. I'm raising this here hoping that it can obtain similar levels of attention as this one.

Jusr wanted to comment on Samuele Pedroni referring to "rudeness" – then I saw that Balazs Gyurak already did: Yes, I saw the comment that has subsequently been removed from this forum post, and Samuele was completely right to object. Please remove this part of your article.

Well, you have the Code of Conduct, and we do not have normal software that would not break user systems. Is there any correlation here we cannot discuss because of the Code of Conduct.

I am very sorry that my rudeness upset such unique snowflakes as the snap team.

The problem is described two years and still present, the importance is "Wishlist".

Is somewhere an open technical discussion about solving the problem in Ubuntu, other than the request to submitting url schemes to the whitelist? In my opinion, this is a fundamental architectural problem and it cannot be solved by PR from a third-party developer.

I also encouter this problem. Each time someone share a zoom link, chronium cannot open it.

This is kind of annoying since it is happenning all day long at each meeting.

I'm thinking about using a different browser just because this bug does not seem importantenough to be solved.

I hope someone takes the time to fix this.

Support for the zoommtg:// protocol was added to snapd with https://github.com/snapcore/snapd/commit/7f678b923c2af8d899bdb2ba95440d62c1c74123. The core snap from the edge channel (2.45~pre1+git1800.7238107) doesn't seem to have the fix yet, though.

Hi folks, the change that @osomon referenced is available in the snapd snap beta channel, can you try the following to see if you are able to open zoom links from the chromium snap now:

```
snap install snapd --beta || snap refresh snapd --beta
```

I tested this on Ubuntu 20.04 and snapd 2.44.5 with the zoom-client snap revision 75 and the chromium snap revision 1135 and it all worked as expected (I used this URL to test zoommtg://zoom.us/join?confno=123456789&pwd=xxxx&zc=0&browser=chrome&uname=Betty).

We are in the process of releasing 2.44.5, and hope to have it available on stable for all users ASAP, but the 20.04 release and a company-wide sprint last week have slightly delayed deploying this fix.

I am happy to see zoom supported, but I can't help being disapointed that slack, vscode, irc, magnet etc still arent. I found this https://github.com/snapcore/snapd/pull/8398#issuecomment-607570865 comment on a PR to add slack which seems to hint that the situation would be resolve in snapd 2.44.2

> dpkg -l | grep snapd
says
> ii snapd 2.44.3+20.04 amd64 Daemon and tooling that enable snap packages

A quick test showed that neither slack nor vscode liveshare github login worked correctly :( is there something wrong with ubuntu's xdg-desktop-portal or is there a special pacakge to install that woudln't be installed by default ?

Hi @jean-helou,

The comment you see was referencing this PR: https://github.com/snapcore/snapd/pull/8289 which unfortunately did not end up making it into 2.44, however I have confirmed that it is in 2.45, which should be released soon. If you would like to test out those changes, please install the snapd from edge:

```
snap install snapd --edge || snap refresh snapd --edge
```

But note that the edge channel may be less stable than the other channels as it automatically pulls in changes from git master daily and so may have more bugs/incomplete features than other channels in snapd. You can always switch back to stable snapd snap with:

```
snap refresh snapd --stable
```

Nevermind my last comment. This works in chromium (no idea about snapd).
To get this to work in chromium, first make sure it works for xdg-open.

Click on the link that you want to be opened automatically in some
application. When it downloaded, right-click on it (the button that
appeared on the bottom) and select "Always open files of this type";
this will cause chromium to use xdg-open next time you open a file
of that type.

To make xdg-open work, run "xdg-mime query filetype the-downloaded-file",
this should print the correct mime type.
Then run "xdg-mime query default that-mime-type", this should print
the desktop file that you want to use, aka "myapplication.desktop".
Inside that .desktop then (.local/share/applications/the-file.desktop),
there should be the lines Exec=/path/your/application and MimeType=that-mime-type
Anyway, plenty of tutorial on xdg on the net. I missed the chromium
trick to make it use xdg-open in the first place.

MS teams & magnet: links both just throw up a "xdg-open" prompt but nothing happens when you "allow".
This should be fixed and released now, right ?

Magnet links are working.

I just tried opening it in Chromium snap and I got the "xdg-open" prompt and than a window with selection between qBittorrent and Transmission. I selected qBittorrent and it opened the magnet link.

$ snap version
snap 2.45
snapd 2.45
series 16
ubuntu 20.04
kernel 5.7.0-xanmod1

Just tested it too, magnet links work for me as well! Thanks

I'm puzzled by all the people tying this to chromium for zoom. I use firefox and it doesn't work any better there, especially with the zoom-client from snap where it doesn't work at all.

Using the snap zoom-client, typing xdg-open 'zoommtg://zoom.us/join?action=join&... (using URL I got by making a test meeting on zoom.us/test) from a shell opens a google search in firefox. Clicking on the same link in firefox does nothing. sudo snap refresh snapd --beta doesn't help. If I install a zoom deb downloaded from zoom.us, xdg-open works on some zoom links, though not all of them.

@akkzilla is right, this is more like a problem of general intercommunication of snaps. It probably needs a decent framework for snaps as a whole, not only the chromium snap.

Snaps do have that concept of plugs and sockets. Shouldn't that be the way of solving this?

Snap 2.45.1 is out now and solves this -- I believe the issue can be marked fixed released.

Fixed for me and i'm on 2.42 Eoan. Dialog appears to choose the app to open.

I recently installed Xubuntu 20.04 and I fail to open magnet links via qBittorrent (installed via apt-get, v4.1.7) :
> snap --version
snap 2.48.1
snapd 2.48.1
series 16
ubuntu 20.04
kernel 5.4.0-58-generic

Using xdg-open it goes well, so seems like the bug discussed here.

Snapd got some extra url handlers added to the whitelist but still not some of those described in the description and comments (irc, ssh, git)

I'm sorry to say we were forced to move from Chromium to Google Chrome (unconfined deb package). I am not at all happy with that, as our software is now less secure than it was before (with the unconfined Chromium). But I never managed to get the snap running for my users, snaps are just not designed to work in networks. Missing URL handlers was the least of our problems.
Not being able to access network shares and snaps caching into the users's homes was what made it unusable.
Very sad that a decision that supposedly was meant to make Chromium more secure has caused right the opposite for us.

Hello,

This bug is not solved at all. After having hit it (xubuntu 21.10, Chromium 96.0.4664.45, snap 2.53.2, I still can not open .vmrc URLs.
When looking at the master git repo here :
https://github.com/jdstrand/snapd/blob/5190924a895e6344b57e9670727bf079d014dbe3/usersession/userd/launcher_test.go#L78
one read that the whitelisted allowedURL schemes are still hard-coded.

Seriously?

I can confirm this is not resolved. Please prioritize a fix as I cannot log into Zoom (SSO based login).

Please make sure that you have xdg-desktop-portal installed, along with xdg-desktop-portal-gtk (or xdg-desktop-portal-kde). The hardcoded list of schemes is a legacy feature which should only be relevant for very old systems such as 16.04 and should not be getting any updates.

Hi, I installed the chromium snap and it's not able to open the locally installed winehq.org compatible Roblox! This is a super huge deal IMHO because having Roblox on Linux is very awesome for the Pipeline of Linux users(the Children) who love to play that game!

Roblox.com (the great creative game for the Children) games only work from the browser-based "Play" button for each game so since xdg-mime / xdg-open for roblox-player cannot be called from the snap based chromium, it breaks roblox.

Roblox.com can be installed on Ubuntu / Linux in winehq.org or to make it easier - with Grapejuice https://brinkervii.gitlab.io/grapejuice/docs/ or even Malik's wrapper at https://github.com/msmalik681/Maliks-Linux-Roblox-Wrapper

Some people are saying to install chromium "from the repo" but that apparently is not an option any more in Ubuntu - it has to come from snap.

Does anyone have a good workaround to setup the whitelist to allow these to work with snap chromium?

# add my roblox launcher to xdg list.
xdg-mime default "roblox-malik.desktop" x-scheme-handler/roblox-player
# add my roblox studio launcher to xdg list.
xdg-mime default "roblox-studio-malik.desktop" x-scheme-handler/roblox-studio
xdg-mime default "roblox-studio-malik.desktop" application/x-roblox-rbxl
xdg-mime default "roblox-studio-malik.desktop" application/x-roblox-rbxlx

Thanks!

Shannon, did you see Maciej's comment just above yours (comment #74) ?

It suggests that this should be handled by the corresponding XDG desktop portal, if installed.
What is your desktop environment? Is the corresponding portal frontend implementation (e.g. xdg-desktop-portal-gtk) installed?