Still, the point is that you have the whole machine at hand. There ought to be a very simple way to make this work.
As explained above, what all system services like NetworkManager/connman (e.g. requesting passwords, opening a website for captive portals), BlueZ (e.g. PIN/passcode, authorization or per user media playback control) are doing is: They delegate the actual “OpenBrowser” action to an agent running as part of the user session. This agent then has the responsibility to process the received action as needed and open a web browser for example. In Ubuntu or gnome this for example is done by nm-applet for NetworkManager or the bluetooth applet for BlueZ.
I don’t see yet how snapd can do this differently.
@robert.ancell Can you help @morphis here. He wants to open a link in the user browser running in the current user session from within the snapd process running as root.
@morphis is right here, by routing the request to open a URL through snapd you lose the ability to prompt the session to launch a browser. As stated above, there is no means for a process outside a session (e.g. snapd as root) can contact the session D-Bus for that session. For that to occur, you would need the external process to have some presence inside the session (like the snapd --user as @morphis suggested). This is how Polkit does it (with the polkit authentication agent contacting the Polkit system service). Don’t underestimate the risk of doing this though, it requires the root daemon to have a level of trust in this session process and ensure it’s not maliciously replaced.
I’ll need to do some research as it’d be great to avoid having another moving piece simply to open a URL. We’ve been there.
So I’ve bumped into an issue using xdg-open in a strictly confined snap of Rambox, which is an Electron app.
I am testing on Ubuntu 16.04 desktop and have snapd-xdg-open installed. If I exclude xdg-utils from the snap clicking URLs within Rambox does nothing. There is no output on stdout/stderr or in the logs. If I include xdg-utils in the snap clicking URLs generates the following on stdout:
Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: x-www-browser: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: firefox: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: iceweasel: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: seamonkey: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: mozilla: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: epiphany: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: konqueror: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: chromium-browser: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: google-chrome: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: www-browser: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: links2: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: elinks: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: links: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: lynx: not found
/snap/rambox-test/x6/usr/bin/xdg-open: 771: /snap/rambox-test/x6/usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening 'https://play.google.com/store/apps/details?id=com.google.android.apps.hangoutsdialer&referrer=utm_source%3Dlandingpage%26utm_campaign%3Dlandingpage&hl=en-GB'
Any bright ideas how to over come this?
yes, you should never include xdg-utils. the core snap currently ships its own xdg-open that will talk via dbus to the snapd-xdg-open service that sits in your user session. if you include xdg-utils in your snap this will override the binary inside the core snap (as you can see in the paths in your error) and send its url open requests nowhere.
is teh electron app actually shelling out to xdg-open or does it use electron.shell to spawn the external process ? note that electron.shell will definitely not work …
the pull reqest below has a working variant …
Thanks for the feedback. Looks like Rambox uses electron.shell:
so i fear you either need to patch it or you need to cheat with awful hacks … (one way would be to add xdg-open to stage-packages, ship a script called “x-www-browser” in your snap that takes the first arg as URL that then calls “/usr/local/bin/xdg-open $URL” (which is the one inside the core snap))
This is wrong. Don’t bundle xdg-open in your snap, that will never work. Just do nothing and assume it is there.
I know it’s wrong. I did it to try and surface errors 
Thanks for the tips. I’ll have an experiment.
So on this do we need to tell all users to install snapd-xdg-open prior to installing our snap? Or how do we handle this? It really seems like it should be automatically installed as a dependency of snapd.
In my snap I can use shell.openExternal in my electron app as well as xdg-open neither work until I install the snapd-xdg-open package.
They’re trying to find a solution which will allow opening links without needing to install snapd-xdg-open, until that solution is found, merged into snapd, and released, you’ll need to tell your users to install snapd-xdg-open. Unfortunately, your users can’t do this on any distribution other than Ubuntu; we’re going to have to wait for opening links to be possible on more distributions.
That’s what I understand from having read the thread, anyway.
Until a solution is found, Corebird (an app I’m asking upstream to provide a Snap for) won’t work at all on non-Ubuntu distributions (since you have to be able to open a link in the browser to log in).
Currently, yes. I’ve also had to prepend /usr/local/bin to my PATH for strictly confined Electron apps using shell.openExternal, like this:
command: env PATH=/usr/local/bin:${PATH} ${SNAP}/bin/desktop-launch $SNAP/opt/Example/example
I’m going to work with Electron Builder upstream to automatically take care of the PATH prepending.
1 Like
You’re quite correct. @zyga-snapd is their an effort to land snapd-xdg-open in other distros as a temporary solution?
There’s ongoing work to land it in Fedora. As for Debian / OpenSUSE I don’t know, @morphis may know more.
Exactly that is what this thread is about. I was discussing with @niemeyer higher up in the thread possibilities to get snapd-xdg-open or a replacement into other distributions. Current status is that @niemeyer want snapd-xdg-open being reworked so that it is build directly into snapd and not being landed into any other distribution. I am still waiting for reply from him after this comment.
@niemeyer explicitly requested me to NOT land snapd-xdg-open into Fedora but work on a replacement instead which we’re still discussing here.