When clinking a link (i.e apt://flameshot) firefox doesn’t open the link on ubuntu software or if I download a file and choose to open instead of keeping it in the download folder
Can you post snap version?
Sorry for the late reply
snap 2.44.3+20.04
snapd 2.44.3+20.04
series 16
ubuntu 20.04
kernel 5.4.0-32-generic
Note that this works fine on chromium. Some times I prefer to search for snaps directly on the website which seems to be faster, When using chromium, clicking install on snapcraft store redirects me to ubuntu software while on firefox it does nothing
If you use snapd 2.45 from the snap via snap install snapd --candidate does it work?
Not fixed on candidate
EDIT: Tried a download to temporary folder and didn’t opened and also tried a snap link which didn’t work also
To be clear, if you download the file to somewhere in ~/Downloads with firefox, then run from a terminal xdg-open <downloaded-file> does the right application open? Or for the case of a URL, does xdg-open apt://flameshot work? I tried this and it seems to work for me, and even from a terminal inside the firefox snap confinement too. Also does snap run --shell firefox -c "xdg-open apt://flameshot" do the expected thing for your system?
If xdg-open from a terminal and from inside the snap works, then this is a problem with the firefox snap not using xdg-open properly, as snapd 2.45 has support for a snap calling xdg-open to just forward the request from inside the snap to xdg-desktop-portal on the host outside of the snap (when it is there), but it seems that firefox is not doing this properly. Perhaps @jamesh or @kenvandine know why this doesn’t work on the firefox snap?
On terminal xdg-open is working fine. The problem is with Firefox
Did you try both the running xdg-open directly and through snap run --shell firefox -c ... ?
Didn’t try this last command should I replace the ... with xdg-open and name of the file?
Please try this command ^
snap run --shell firefox -c "xdg-open apt://flameshot"
user-open error: Supplied URL scheme "apt" is not allowed
Tried also with snap and it opened on ubuntu-software, but if I ckick on the link on snapcraft.io it doesn’t open
snap run --shell firefox -c "xdg-open snap://opera"
Interesting with snapd 2.45+git607.gda0d2c2 this just works for me. Can you try maybe with snapd snap from edge? i.e. snap refresh snapd --edge ?
Still the same error on edge
snap run --shell firefox -c "xdg-open apt://flameshot"
user-open error: Supplied URL scheme "apt" is not allowed
snap 2.45+git607.gda0d2c2
snapd 2.45+git607.gda0d2c2
series 16
ubuntu 20.04
kernel 5.4.0-32-generic
Firefox is using GLib’s GAppInfo API to launch associated applications, which is an implementation of the XDG MIME specification, rather than invoking xdg-open directly.
In the current builds of the Firefox snap, we used a mimeapps.list file to map many common mime types to the xdg-open.desktop file provided by the base snap:
As this file does not set the mime type x-scheme-handler/apt, Firefox does not believe xdg-open.desktop can handle apt: URIs.
Things are a bit different in the tip branch of the mozilla repository:
https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/docker/firefox-snap
There’s no mimeapps.list file any more, and the snapcraft.yaml now sets GTK_USE_PORTAL=1 in the environment. This causes the GLib APIs to ask xdg-desktop-portal to open any files it can’t otherwise find a handler for.
The other change in tip is to set $TMPDIR to somewhere other than /tmp (specifically, it sets it to ~/Downloads/firefox.tmp). When Firefox tries to open a file of a type it doesn’t understand, it downloads and saves a copy of it to the temp files directory, and then tries to open that file with its associated handler. This is a problem for snaps, since /tmp inside the sandbox is different to /tmp outside of the sandbox. Using a different location allows the file to be passed to the helper outside the sandbox.
Sadly both of these changes are from after the Firefox 77 branch point, so none of the channels contain a snap with these fixes at present.
2 Likes
So can we assume that this will be fixed on next release? If yes, we can assume this as solved.
The current release is 76.0.1 with 77.0 in the beta channel. It’s not clear whether this will be included in a 77.x release.
I’m on Firefox 80 in the beta channel, and files and folders won’t open up. Probably related to this.
I’m on KDE Neon 20.04 if that helps
Here’s the bug report.
1 Like
There’s a similar problem opening PDFs from VSCode by means of texdoc using the LaTeX Workshop extension: https://github.com/James-Yu/LaTeX-Workshop/issues/2437 Any workaround maybe?
This has been solved a few release ago, marking as solved