With on-going work to integrate xdg-open into snapd (PR) xdg-open becomes more widely available to snaps. snapd will also be fully in control of the implementation. It seems like another step to make it more easily-accessible would be to untie it from the unity7 interface. Currently, the interface is needed, even though xdg-open itself doesn’t depend on a particular desktop session. It’s not even X11-specific by design: terminal browsers like w3m and links are supported.
So I think it would make sense to expose it unconditionally.
Yes, and our xdg-open calls out into a service outside the snap which is supposed to be safe to use. So indeed it seems fine to drop that requirement for the time being.
What’s the status on using xdg-open without interface by now? plugs: desktop does not work for me, xdg-open raises:
httpd: socket: Permission denied
plugs: unity7 works, but gives a warning when pushing to the store:
desktop interfaces (unity7) specified without a corresponding meta/gui/.desktop file. If using snapcraft, please see https://snapcraft.io/docs/build-snaps/metadata#fixed-assets. Otherwise, please provide a desktop file in meta/gui/.desktop (it should reference one of the ‘apps’ from your snapcraft/snap.yaml).
There has been no change here, but I’m not sure how this would make a difference to you: if things aren’t working for you with the desktop interface plugged, then they would likely also fail if those security declarations are moved to the base template.
It’s particularly puzzling if unity7 works but desktop fails. What exactly is your app doing when you hit this failure case?
Thanks for the reply @jamesh. It was a mistake on my side. Apparently the plugs network and network-bind are included in unity7. When switching to desktop these were missing, causing the error mentioned above. It works fine now.
So the error message was not caused by using xdg-open, but from the missing network and network-bind statements.
