I’m running Fedora 39 (XFCE) and am having trouble opening links from flatpak applications. When I click on a link, nothing happens. If I run the app with --log-session-bus, I see this message logged
Failed to call portal: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface ?org.freedesktop.portal.OpenURI? on object at path /org/freedesktop/portal/desktop
Doing some googling about this, I found that I need to install xdg-desktop-portal, but it seems that it was already installed for me
This is what I’ve taken to calling the portalpocalypse. xdg-desktop-portal 1.18 has dropped the fallback that would use the first available backend, so if your desktop environment doesn’t have one of the new portal configuration files, you get nothing.
XFCE upstream has added one, but it needs to be backported into the Fedora package. Please file a bug against xfce4-session in Fedora.
For now, you can create it yourself: ~/.config/xdg-desktop-portal/xfce-portals.conf:
aha, so it does work if I run it with this command, but after a reboot it doesn’t work on its own.
From that command:
XDP: Default handler firefox for https, x-scheme-handler/https
XDP: Recommended handlers for https, x-scheme-handler/https: chromium-browser, firefox
XDP: Can skip app chooser for x-scheme-handler/https
XDP: Found in permission store: handler: (null), count: 0 / 3, always ask: 0
XDP: Allowing to skip app chooser: can use default
XDP: Skipping app chooser
XDP: Launching firefox [link]
This is perhaps a silly question, but what normally runs this? I see that the xdg-desktop-portal rpm includes a systemd service, but even after making sure that was running, links didn’t work
It’s a D-Bus session service that is autostarted on first access: /usr/share/dbus-1/services/org.freedesktop.portal.Desktop.service. That file contains SystemdService=xdg-desktop-portal.service, which defers to the systemd user manager if available.
This works well on GNOME, but I’m not sure what populates systemd’s environment on XFCE (e.g. DISPLAY).
What does systemctl --user status xdg-desktop-portal.service say?
● xdg-desktop-portal.service - Portal service
Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
Drop-In: /usr/lib/systemd/user/service.d
└─10-timeout-abort.conf
Active: active (running) since Fri 2023-11-10 22:18:57 EST; 1min 14s ago
Main PID: 6323 (xdg-desktop-por)
Tasks: 6 (limit: 37440)
Memory: 3.7M
CPU: 281ms
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/xdg-desktop-portal.service
└─6323 /usr/libexec/xdg-desktop-portal
Nov 10 22:18:57 scooty-puff-jr systemd[1842]: Starting xdg-desktop-portal.service - Portal service...
Nov 10 22:18:57 scooty-puff-jr systemd[1842]: Started xdg-desktop-portal.service - Portal service.
One interesting thing worth noting is that links do work if I rename xfce-portals.conf to portals.conf. From man 5 portals.conf
Users can override those defaults, or provide configuration for an otherwise unsupported desktop envi‐
ronment, by writing a file ˜/.config/xdg-desktop-portal/portals.conf. Users of more than one desktop
environment can use desktop-specific filenames such as kde-portals.conf which will only be used in the
appropriate desktop environment.
I wonder if somehow it’s not being informed of my desktop environment properly…?
Double-posting here, but an interesting note; I checked the source code for x-d-p and it looks like the desktop environment it chooses is based on XDG_CURRENT_DESKTOP. If I check env, this is indeed XFCE (which explains why everything worked when I ran the command by hand). I wonder if in the environment it is executing, this is not set…
Fascinating. Shouldn’t my login manager normally set that…? Well, I’m glad it works, but I’ll file a bug report for this tomorrow (first time for everything, haha).