X-www-browser and xdg-open

I am trying each day to improve the liferea snap

When the snap is not confined, I can open links in my default browser, but with strict confinement it fails. I found that the problem is that it uses x-www-browser (the default browser in debian systems). I used a shell in the snap and see that there is no such command. So, I thought to use the xdg-open command instead. But it fails again. If I use it from the a shell inside the snap it fails quietly .

alejo @ ~ - [] $ snap run --shell liferea
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

alejo@steven:/home/alejo$ xdg-open https://www.google.com
alejo@steven:/home/alejo$ 

I found in the forums a lot of people with similar problems. So… I am missing something here? Is some config needed to use the xdg-open command?

Thanks

The xdg-open inside the sandbox just performs a D-Bus call to a process outside the sandbox, asking it to open the URL (using the xdg-open found outside of confinement). If that command returned an error, you should have seen that reported in the sandbox.

Does running xdg open https://www.google.com outside of the snap sandbox work correctly?

It workds outside the sandbox but fails inside. This is an example

alejo @ ~ - [] $ xdg-open https://www.google.com
alejo @ ~ - [] $ snap run --shell liferea
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

alejo@steven:/home/alejo$ xdg-open https://www.google.com
alejo@steven:/home/alejo$ 

The first call to xdg-open works. It opened a tab with google

The second call did nothing.

This is even weirder. I have other snap, bastet (https://github.com/almejo/bastet-snap). Inside that snap xdg-open doesnt work either becouse it says.

alejo @ ~ - [] $ snap run --shell bastet
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

alejo@steven:/home/alejo$ xdg-open https://google.com
bash: /usr/bin/xdg-open: Permission denied

Both snaps use strict confinement, so maybe some plug?

You must plugs ‘desktop’ to use xdg-open. If after doing that your problem is still not solved, be sure that your snap is not shipping xdg-open from stage-packages and accidentally using it (eg, find /snap/yoursnap/current/ -name xdg-open should come back empty. If it doesn’t, you should either remove it (eg, using ‘stage’ in snapcraft.yaml; this is the easiest option), ensure that the PATH is setup so that /usr/bin is before $SNAP/usr/bin (or wherever xdg-open is)) or if using layouts, that the layout isn’t redirecting /usr/bin/xdg-open to something in your snap/putting something in your snap before /usr/bin/xdg-open in your PATH.

The snap has the desktop plug, but also has the desktop-legacy. Can be that a problem?

The problem persists. I have not included xdg-open

$ find /snap/liferea/ -name xdg-open
$

Also, this is the content of xdg-open inside the snap

alejo @ ~/mysnaps/liferea-snap - [master] $ snap run --shell liferea
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

alejo@steven:/home/alejo/mysnaps/liferea-snap$ which xdg-open
/usr/bin/xdg-open
alejo@steven:/home/alejo/mysnaps/liferea-snap$ cat /usr/bin/xdg-open
#!/bin/sh
exec snapctl user-open "$@"
alejo@steven:/home/alejo/mysnaps/liferea-snap$

For what it is worth, when I installed your liferea snap from the edge channel, xdg-open seemed to run fine from the snap run --shell liferea shell.

Is there anything unusual about your system? What desktop environment and distribution are you running?

:expressionless:

I run ubuntu 20.04 with gnome. I upgraded from 4.10 to 18.04 without stop, but for then I installed from scratch and then upgraded to 18.10, 19.04, 19.10.

I have not booted my machine in a couple of days. I will try that in a couple of hours (working now in other machine).

Is there a log to see something? Snappy.scan-logs shows nothing

I will try from a virtual machine for further information