`xdg-desktop-portal.service` started without required environment variables on login

[hcsch]

Describe the bug

Calling the org.freedesktop.portal.OpenURI.OpenFile method the xdg-desktop-portal with gdbus (either directly or through xdg-open which uses it to open files) always fails with reason 2 ("The user interaction was ended in some other way", see docs).

When setting the ask option to true (see docs), no dialog is opened in which to choose an app (unlike with org.freedesktop.portal.OpenURI.OpenURI, where a dialog is openend and choosing an app opens the URI in that app). The same response is returned.

My DE is GNOME 45 (from nixos-unstable) running a Wayland session.

Steps To Reproduce

Steps to reproduce the behavior:

0. Be running a Wayland session of GNOME 45
1. Start dbus-monitor to monitor requests and responses
2. Run gdbus call --session --dest org.freedesktop.portal.Desktop --object-path /org/freedesktop/portal/desktop --method org.freedesktop.portal.OpenURI.OpenFile --timeout 5 '' 3 '{}' < <path-to-a-html-file>
3. Observe how the browser (in my case firefox) isn't being opened, even though it is available for the OpenURI call
4. Observe the response singal of (uint32 2, array []) in the dbus-monitor output

Expected behavior

The dbus call to org.freedesktop.portal.OpenURI.OpenFile via gdbus succeeds and causes the file to be opened in the appropriate app (in the case of a html file, the default browser). Calling the dbus method with the ask option set to true opens a picker dialog in which an app can be chosen.

xdg-open <html-file> succeeds and opens the default browser with the given file.

Additional context

Very likely related to https://github.com/NixOS/nixpkgs/issues/189851. Not sure though if this is quite the same issue, but both issues have something to do with the desktop portal. If you believe this to be the same issue, feel free to close (apologies in that case).

Notify maintainers

@edolstra @jtojnar

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.8, NixOS, 24.05 (Uakari), 24.05.20240102.bd645e8`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

---

Add a :+1: reaction to issues you find important.

[jtojnar]

Works for me just fine here (GNOME Wayland session, same nixos-unstable version).

Though note that the syntax is actually as follows:

gdbus call --session --dest org.freedesktop.portal.Desktop --object-path /org/freedesktop/portal/desktop --method org.freedesktop.portal.OpenURI.OpenFile --timeout 5 '' 3 '{"ask": <true>}' 3<~/foo.html

The 3 is a file descriptor number and you need to redirect the file to that file descriptor. ~/foo.html is a file path.

[hcsch]

... Sorry and thanks for pointing that out. I somehow missed that 3 in the source of xdg-open. Makes sense that you'd have to specify that as the target fd in the bash redirection. With that opening a text file now works.

With that help I've just discovered what my actual issue is: xdg-desktop-portal.service seems to get started without the right environment variables set. After a fresh boot I get Error: no DISPLAY environment variable specified by firefox in the logs of the service, when trying to open a html file. Restarting the service from a terminal emulator with systemctl --user restart xdg-desktop-portal.service seems to fix the issue. I have the portal enabled with xdg.portal.enable and xdg.portal.xdgOpenUsePortal set.

https://github.com/NixOS/nixpkgs/issues/189851 is also environment variable related, but as far as I could tell, mostly focused on PATH? I'll rename this issue to match what I described above and will see if I can find a way to fix the environment variable issue I'm likely having.

[jtojnar]

That is weird. GNOME should just work – the module sets the portals correctly:

https://github.com/NixOS/nixpkgs/blob/40830f825335d4f5400a5337e9139fe43113a69e/nixos/modules/services/x11/desktop-managers/gnome.nix#L348-L356

And the activation environment should be handled by session as well.

[hcsch]

I just compared the output of env in a terminal emulator to the output of sudo strings /proc/<service-pid>/environ and the following (possibly relevant-ish) environment variables are missing:

• DBUS_STARTER_ADDRESS
• DBUS_STARTER_BUS_TYPE
• DISPLAY
• GNOME_SETUP_DISPLAY
• SESSION_MANAGER
• WAYLAND_DISPLAY
• XAUTHORITY

Various xdg environment variables, nix, gdm, gio, etc. variables are set though. Including DESKTOP_SESSION, GTK_PATH and the like.

[LunNova]

I've seen this for i3 before due to the way graphical-session.target gets started or due to services.xserver.windowManager.i3.updateSessionEnvironment being disabled.

Bodge for graphical-session.target issue: https://github.com/LunNova/nixos-configs/blob/abb5e7e8f124fd2680e05b3bd74f73983b4dcd2d/nixpkgs-patches/graphical-session-delay.patch

I don't use gnome but it might be related to the same issue on i3

[LunNova]

If systemctl restart --user '*xdg*' temporarily fixes it then it's a timing issue and env vars were imported into the systemd user environment after portal start. If that doesn't fix it, it's something else.

[hcsch]

It's exactly as you say. The variables do get imported into the systemd user environment, the xdg-desktop-portal service just seems to be started before that happens. Restarting it resolves the issue. Not quite sure how to get the service started at the right time, but I'll have a look again some time soon.