search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
16.46k stars 12.95k forks source link

Apps launched by xdg-open can misbehave when called from FHS envs or wrapped programs #160923

Open LunNova opened 2 years ago

LunNova commented 2 years ago

Describe the bug

When calling xdg-open from a FHS env or wrapped app, it tries to launch the associated program directly while either having unexpected/unrelated environment variables like LD_PRELOAD set or worse being in an FHS env which is entirely missing some dependencies.

Ideally, xdg-open when used in a FHS env or wrapped package would use xdg-desktop-portal to launch apps instead, similarly to how flatpaks use this to open other applications outside of the package.

There is partial upstream support for this but it only applies in flatpaks:
https://github.com/freedesktop/xdg-utils/blob/1a58bc28f6844898532daf9ee1bf6da7764955a9/scripts/xdg-open.in#L250
https://github.com/freedesktop/xdg-utils/blob/d11b33ec7f24cfb1546f6b459611d440013bdc72/scripts/xdg-utils-common.in#L361-L363
It also doesn't handle local files correctly.

An example script which also handles files is here.

Steps To Reproduce

One example of this issue, although there are many related issues in different contexts.

Steps to reproduce the behavior:

  1. Launch lutris under KDE
  2. Click a link in it or an app launched by it
  3. KDE thinks firefox's .desktop item isn't owned by root as it's owned by nobody in the FHS sandbox and refuses to start it

Expected behavior

The xdg-open package in NixOS should use xdg-desktop-portal to launch apps/urls/etc when possible as if it is inside a flatpak to avoid running apps in unexpected FHS envs or with unexpected env from wrappers.

Screenshots

Opening a link in FFXIV under lutris Error if you click yes

Notify maintainers

@edolstra - xdg-utils maintainer entry @Atemu @illegalprime @wentasah - work on bwrap FHS envs

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 5.15.19-xanmod1-tt, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.7.0pre20220127_558c4ee`
 - channels(root): `"nixos-21.11.333896.a640d8394f3"`
 - channels(lun): `""`
 - nixpkgs: `/etc/nix/path/nixpkgs`
LunNova commented 2 years ago

Related issues:

LunNova commented 2 years ago

Related discourse threads:

Atemu commented 2 years ago

The xdg-open package in NixOS should use xdg-desktop-portal to launch apps/urls/etc when possible as if it is inside a flatpak to avoid running apps in unexpected FHS envs or with unexpected env from wrappers.

Before we reinvent any wheels, how does Flatpak solve this problem?

LunNova commented 2 years ago

xdg-utils detects $XDG_RUNTIME_DIR/flatpak-info existing and uses xdg-desktop-portal. This implementation is incomplete and will only handle URLs but hopefully it wouldn't be too hard to get local file support added upstream like in the script I linked.

I'm not sure if making xdg-open think it's in a flatpak in general is safe or if it'd be better to get a more nix-specific toggle added.

Atemu commented 2 years ago

I'm not sure if making xdg-open think it's in a flatpak in general is safe

I mean, it basically is?

Is there a non-Flatpak-specific way to handle portals? I imagine Snap and AppImage must be doing it somehow too. If they also use the Flatpak method, we should use it too. If they use a more generic way, we should use that.

LunNova commented 2 years ago

I was concerned that telling xdg-utils it's in a flatpak by making sure that flatpak-info exists would cause problems with unrelated things.

nixos-discourse commented 2 years ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/who-uses-nixos-with-kde/18212/10

PAI5REECHO commented 2 years ago

So is this why links from Discord open in Chrome instead of my default browser? :thinking:

LunNova commented 2 years ago

@PAI5REECHO

So is this why links from Discord open in Chrome instead of my default browser? thinking

It's possible although it's probably not that, it's more likely an issue with the xdg associations.

If you use home-manager, try something like xdg-mime-apps.nix

PAI5REECHO commented 2 years ago

@LunNova

it's more likely an issue with the xdg associations

It's not that, firefox is the only thing I have set in my .config/mimeapps.list

LunNova commented 2 years ago

I've implemented a workaround for this as a nixos module which is exposed at nixosModules.xdg-open-workaround in github:LunNova/nixos-configs/dev.

Implementation at https://github.com/LunNova/nixos-configs/blob/dev/modules/exported/xdg-open-workaround.nix and https://github.com/LunNova/nixos-configs/blob/dev/packages/xdg-open-with-portal/default.nix

Is this approach worth upstreaming?

ShamrockLee commented 2 years ago

Is #176962 related to this issue?

SuperSandro2000 commented 2 years ago

@LunNova yes please

schlichtanders commented 1 year ago

I've implemented a workaround for this as a nixos module which is exposed at nixosModules.xdg-open-workaround in github:LunNova/nixos-configs/dev.

Implementation at https://github.com/LunNova/nixos-configs/blob/dev/modules/exported/xdg-open-workaround.nix and https://github.com/LunNova/nixos-configs/blob/dev/packages/xdg-open-with-portal/default.nix

Is this approach worth upstreaming?

I would be glad if this problem can be solved generically, as it effects many applications (for me for example zettlr and marktext). I haven't tried your workaround, but it looks good when looking at the files.

@LunNova How can I install your nixos module?

LunNova commented 1 year ago

Add github:LunNova/nixos-configs/main as a flake input:

inputs = {
  ...
  lunnova-nixos-configs.url = "github:LunNova/nixos-configs/main";
  ...
}

Add it as an argument to outputs, then add lunnova-nixos-configs.nixosModules.xdg-open-workaround into the modules list you're passing to lib.nixosSystem.

Not sure how best to do it if you don't use flakes.

I'll try to get a PR to include this in nixpkgs shortly.

deifactor commented 1 year ago

@LunNova I haven't completely tried your approach, but one thing I noticed is that on my system ulimit -Sn is 1024, so just running exec 9999< /some/file fails. Maybe pick your favorite three-digit number as the fd?

LunNova commented 1 year ago

Been somewhat distracted, hope to make a PR for this tonight. (Yes, this comment is an accountability post for myself so I'll actually do it :))

LunNova commented 1 year ago

Draft PR up here: #187293

LunNova commented 1 year ago

@deifactor I swapped it to use bash's "new" (from 2009 lol) syntax for auto selecting an available FD instead, hopefully that works on your machine!

deifactor commented 1 year ago

Looks like it works (that is, exec {foo}< /etc/passwd; echo $foo echoes 10, so I assume this means the syntax is compatible). Thanks!

deifactor commented 1 year ago

Not commenting on the quality of the fix itself, more "how did we get here".

So if I understand correctly, the problem is that your FHS application can have an arbitrary environment, which get passed to xdg-open, which get in turn passed down to Firefox. On most distributions, this isn't a problem because you don't do weird stuff with environment variables (or if you do, you do so for your entire user session so you'll break firefox immediately), but nixpkgs' isolation means that the FHS application might have LD_PRELOAD, LD_LIBRARY_PATH, or some other weird thing set that isn't set when invoking it normally.

  1. Doesn't any solution that involves gdbus (or any 'wrapper' program) run the risk of having the same issue if you set some env variable in a way that makes gdbus sad?
  2. Can we fix this by just having xdg-open clear out variables that are suspected to be problematic (LD_*)? Obviously having any fix is better than nothing, but it feels a little weird that this solution relies on the fact that portals happen to exist, if that makes sense.
LunNova commented 1 year ago

Doesn't any solution that involves gdbus (or any 'wrapper' program) run the risk of having the same issue if you set some env variable in a way that makes gdbus sad?

Yes, but it has a limited scope as once you manage to make a dbus call you're talking to the portal which isn't inheriting your environment, and it's only one combination to test (your program's env/fhs + gdbus) instead of your program's env/fhs + any other program in your system it might launch.

Can we fix this by just having xdg-open clear out variables that are suspected to be problematic (LD_*)? Obviously having any fix is better than nothing, but it feels a little weird that this solution relies on the fact that portals happen to exist, if that makes sense.

This works for wrapped programs but not FHS envs. FHS envs use namespaces/cgroups, you can't undo this just by clearing an environment variable.

If your solution only needs to work for wrapped programs, clearing a set of env variables works.

deifactor commented 1 year ago

Ah, I wasn't aware of that re: FHS envs. (How that all works is not exactly within my wheelhouse.)

LunNova commented 1 year ago

Opened #197118 with an alternative approach. (#187293 was the original which relied on xdg-open in PATH working or would cause mass rebuilds toggling the setting)

Looking for help getting either approach in.

nixos-discourse commented 1 year ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-in-distress/3604/56

LunNova commented 1 year ago

197118 has been merged so xdg.portal = { enable = true; xdgOpenUsePortal = true; } should work around this issue.

Please report here if it causes any new bugs or does not resolve your issue, along with your desktop environment and the app involved.

huantianad commented 1 year ago

@LunNova Is there a way to have xdg-open still support file:// URIs when using xdgOpenUsePortal = true? I noticed xdg-open uses org.freedesktop.portal.OpenURI.OpenURI which explicitly doesn't support file:// URIs, and that you also mentioned this in the upstream PR.

If there's no fix for this, it might be worth it to mention it in the option's description, since many applications rely on file:// URIs.

LunNova commented 1 year ago

We can probably patch support in in nixpkgs' version. I still haven't heard anything from upstream about the last PR which is inconvenient for getting it fixed for everyone :/

huantianad commented 1 year ago

Sounds good, is it a simple patch to open_flatpak that checks for the file protocol and uses OpenURI.OpenFile/OpenURI.OpenDirectory instead?

huantianad commented 1 year ago

As a temporary workaround for my system, I'm using flatpak-xdg-utils, which provides its own xdg-open that works with file://.

https://github.com/huantianad/nixos-config/commit/147cb7e91d75d4764eb031875b8e527e1927be21 the main annoyance here is that it causes a rebuild of a bunch of applications that I don't want to build locally (like chromium) 😅

VAWVAW commented 1 year ago

I am experiencing #189851 while trying this with a standalone wm. Just in case someone has the same issue.

MathiasSven commented 1 year ago

It seems that when I tried using this option xdgOpenUsePortal = true it fixed my issue where I couldn't open links from within vscode-fhs however now I had problems using xdg-open command from the terminal normally, which also made so some python application wouldn't open an image because it relied on this command. As an example:

~ ✦ ❯ xdg-open background.png
(objectpath '/org/freedesktop/portal/desktop/request/1_11449/t',)

~ ✦ ❯

No image would open and I would just get that printed to stderr. Turning this option off and logging off and back on solved the issue but then I am back to not being able to open links in FHS. I am not really sure how but it seems this option messes up with my non FHS environment.

lilyinstarlight commented 1 year ago

I've opened PR #217590 with a fix for using xdg-open on filenames when xdgOpenUsePortal = true

chenlijun99 commented 1 year ago

@lilyinstarlight Thanks for your patch. A few days ago it landed on NixOS unstable so I tried it.. It seems that it fixed opening folders with xdg-open but didn't fix opening files. I'm still having the same behaviour that @MathiasSven showed in https://github.com/NixOS/nixpkgs/issues/160923#issuecomment-1411872545

chenlijun99 commented 1 year ago

TL;DR;

The plasma-xdg-desktop-portal-kde needs an additional plasma-workspace package as build input.

Ok. Got the reason.

It turns out that with the new patched xdg-open it is possible to open some files, while for some other files it does nothing. I am using plasma-xdg-desktop-portal-kde as backend for xdg-desktop-portal and for every xdg-open invocation that "does nothing", I could see the following log from plasma-xdg-desktop-portal-kde. 

xdg-desktop-portal-kde[3318]: QQmlApplicationEngine failed to load component
xdg-desktop-portal-kde[3318]: qrc:/AppChooserDialog.qml:15:1: module "org.kde.plasma.w>
xdg-desktop-portal-kde[3318]: QObject::connect: Cannot connect (nullptr)::accept() to >
xdg-desktop-portal-kde[3318]: QObject::connect: Cannot connect (nullptr)::reject() to >
xdg-desktop-portal-kde[3318]: Failed to load dialog, cannot exec

I suspected that the files that worked were the files for which plasma-xdg-desktop-portal-kde was able to pick a default program to use to open the file, while for the files that didn't work plasma-xdg-desktop-portal-kde tried to open an application picker dialog but failed and printed those logs. Thus I tried to add the dependency (plasma-workspace) that is presumably missing to the xdg-desktop-portal-kde package. I did it via overlay.

let
  pkgs-unstable = import inputs.nixpkgs-unstable {
    system = pkgs.system;
  };
in {
  nixpkgs.overlays = [
    (final: prev: {
      xdg-desktop-portal-kde = pkgs-unstable.xdg-desktop-portal-kde.overrideAttrs (oldAttrs: rec {
        buildInputs = oldAttrs.buildInputs ++ [pkgs-unstable.plasma-workspace];
      });
    })
  ];
}

After applying this change, indeed xdg-open started to open an application picker for the files that previously didn't work.

huantianad commented 1 year ago

@chenlijun99 interesting, I haven't had any issues with opening files, but actually when opening directories, if dolphin is already open, but I use xdg-open to open a new folder that isn't already open in the existing dolphin, it'll instead open a completely new instance of dolphin instead of opening it in my existing dolphin window. I'd assume this is a dolphin bug, but I can't seem to find it online anywhere. Wanted to mention this in case anyone else had this same issue and had a fix.

MathiasSven commented 1 year ago

@chenlijun99 I assume this could just be PRed then no?

Atemu commented 1 year ago

Could those affected test the PR above?

Eisfunke commented 1 year ago

I made some notes during my efforts with this problem in the hope that it might be helpful:

I'm using wayland with sway and xdg-desktop-portal-wlr and xdg-desktop-portal-gtk. For reference, my config.

Finally, some logs dbus-monitor spews out when running xdg-open. Interesting stuff seems to be mostly in the end. My observations: it seems to have found vivaldi-stable.desktop, which is indeed the desktop file it should use to launch the link. Also, the final message is:

error_name=org.freedesktop.DBus.Error.ServiceUnknown reply_serial=777
   string "The name :1.346 was not provided by any .service files"

and 346 is the number that xdg-open showed in the objectpath message from above. So yeah, no idea what's happening there.

dbus logs ``` method call time=1681858691.949944 sender=:1.345 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello method return time=1681858691.949962 sender=org.freedesktop.DBus -> destination=:1.345 serial=1 reply_serial=1 string ":1.345" signal time=1681858691.949973 sender=org.freedesktop.DBus -> destination=(null destination) serial=740 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.345" string "" string ":1.345" signal time=1681858691.949990 sender=org.freedesktop.DBus -> destination=:1.345 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.345" method call time=1681858691.950061 sender=:1.345 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner string "org.gnome.SessionManager" error time=1681858691.950070 sender=org.freedesktop.DBus -> destination=:1.345 error_name=org.freedesktop.DBus.Error.NameHasNoOwner reply_serial=2 string "Could not get owner of name 'org.gnome.SessionManager': no such name" signal time=1681858691.950322 sender=org.freedesktop.DBus -> destination=:1.345 serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost string ":1.345" signal time=1681858691.950339 sender=org.freedesktop.DBus -> destination=(null destination) serial=741 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.345" string ":1.345" string "" method call time=1681858691.970429 sender=:1.346 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello method return time=1681858691.970447 sender=org.freedesktop.DBus -> destination=:1.346 serial=1 reply_serial=1 string ":1.346" signal time=1681858691.970458 sender=org.freedesktop.DBus -> destination=(null destination) serial=742 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.346" string "" string ":1.346" signal time=1681858691.970472 sender=org.freedesktop.DBus -> destination=:1.346 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.346" method call time=1681858691.970575 sender=:1.346 -> destination=org.freedesktop.portal.Desktop serial=2 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.DBus.Introspectable; member=Introspect method return time=1681858691.970999 sender=:1.6 -> destination=:1.346 serial=772 reply_serial=2 string " " method call time=1681858691.971556 sender=:1.346 -> destination=org.freedesktop.portal.Desktop serial=3 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.portal.OpenURI; member=OpenURI string "" string "https://nixos.org" array [ ] method call time=1681858691.971733 sender=:1.6 -> destination=org.freedesktop.DBus serial=773 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetConnectionUnixProcessID string ":1.346" method return time=1681858691.971746 sender=org.freedesktop.DBus -> destination=:1.6 serial=276 reply_serial=773 uint32 55581 method return time=1681858691.971934 sender=:1.6 -> destination=:1.346 serial=774 reply_serial=3 object path "/org/freedesktop/portal/desktop/request/1_346/t" signal time=1681858691.972200 sender=org.freedesktop.DBus -> destination=:1.346 serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost string ":1.346" signal time=1681858691.972211 sender=org.freedesktop.DBus -> destination=(null destination) serial=743 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.346" string ":1.346" string "" method call time=1681858691.973147 sender=:1.6 -> destination=:1.8 serial=775 path=/org/freedesktop/impl/portal/PermissionStore; interface=org.freedesktop.impl.portal.PermissionStore; member=Lookup string "desktop-used-apps" string "x-scheme-handler/https" error time=1681858691.973240 sender=:1.8 -> destination=:1.6 error_name=org.freedesktop.portal.Error.NotFound reply_serial=775 string "No entry for x-scheme-handler/https" signal time=1681858691.975112 sender=:1.6 -> destination=(null destination) serial=776 path=/org/gtk/gio/DesktopAppInfo; interface=org.gtk.gio.DesktopAppInfo; member=Launched array of bytes "/etc/profiles/per-user/eisfunke/share/applications/vivaldi-stable.desktop" + \0 string "" int64 55590 array [ string "https://nixos.org" ] array [ dict entry( string "origin-prgname" variant array of bytes "/nix/store/90x9iwapqqm28w6nli53256i18l5jb04-xdg-desktop-portal-1.15.0/libexec/xdg-desktop-portal" + \0 ) dict entry( string "origin-pid" variant int64 2084 ) ] signal time=1681858691.975591 sender=:1.6 -> destination=:1.346 serial=777 path=/org/freedesktop/portal/desktop/request/1_346/t; interface=org.freedesktop.portal.Request; member=Response uint32 0 array [ ] error time=1681858691.975602 sender=org.freedesktop.DBus -> destination=:1.6 error_name=org.freedesktop.DBus.Error.ServiceUnknown reply_serial=777 string "The name :1.346 was not provided by any .service files" ```
unode commented 1 year ago

So is this why links from Discord open in Chrome instead of my default browser? thinking

I'm having a similar but with joplin-desktop and in my case Chromium is launched instead despite not even being mentioned in XDG outputs (see below).

I have enabled xdg.portal in nixos-22.11 though:

  xdg.portal = {
    enable = true;
    xdgOpenUsePortal = true;
    extraPortals = [ pkgs.xdg-desktop-portal-gtk ];
  };

Chromium is not even among the default http/https handlers:

% nix-shell --pure -p glib
$ gio mime x-scheme-handler/https
Default application for ?x-scheme-handler/https?: userapp-Firefox-IN1NE1.desktop
Registered applications:
    userapp-Firefox-IN1NE1.desktop
    google-chrome.desktop
Recommended applications:
    userapp-Firefox-IN1NE1.desktop
    google-chrome.desktop

$ gio mime x-scheme-handler/http
Default application for ?x-scheme-handler/http?: userapp-Firefox-IN1NE1.desktop
Registered applications:
    userapp-Firefox-IN1NE1.desktop
    google-chrome.desktop
Recommended applications:
    userapp-Firefox-IN1NE1.desktop
    google-chrome.desktop

Using gio open http:// opens a new Firefox window, as does https://...

Awfully confused about this. :thinking:

lilyinstarlight commented 1 year ago

@unode These things run under the xdg-desktop-portal systemd user service

Can you see if systemd-run --user -t gio mime x-scheme-handler/https correctly shows the default?

If not, you may need to make sure XDG_DATA_DIRS+PATH is correctly imported/set for systemd user scope (I did actually consider adding a systemd.user.services.xdg-desktop-portal.path = lib.mkAfter [ "/run/current-system/sw" ] to the xdg portal module in NixOS, so that the behavior is less surprising by default)

unode commented 1 year ago

@lilyinstarlight 

% systemd-run --user -t gio mime x-scheme-handler/https
Running as unit: run-u37615.service
Press ^] three times within 1s to disconnect TTY.
Default application for “x-scheme-handler/https”: userapp-Firefox-IN1NE1.desktop
Registered applications:
    userapp-Firefox-IN1NE1.desktop
    firefox.desktop
    chromium-browser.desktop
    google-chrome.desktop
Recommended applications:
    userapp-Firefox-IN1NE1.desktop
    firefox.desktop
    chromium-browser.desktop
    google-chrome.desktop

and a similar output for http/https.

It doesn't explain why Firefox isn't launched. But at least it's clear where Chromium is coming from.

Adding /run/current-system/sw to PATH configuration doesn't seem to make a difference.

lilyinstarlight commented 1 year ago

@unode If you drop into an interactive shell with systemd-run --user -t -S, are you able to get firefox to open with gio open https://nixos.org/?

unode commented 1 year ago

@lilyinstarlight yes. Both gio open and xdg-open open a new nixos.org tab in Firefox:

% systemd-run --user -t -S
Running as unit: run-u38802.service
Press ^] three times within 1s to disconnect TTY.
% gio open https://nixos.org/
% xdg-open https://nixos.org/
(objectpath '/org/freedesktop/portal/desktop/request/1_38806/t',)
lilyinstarlight commented 1 year ago

Wait. So xdg-open there (which still goes through portal) opens firefox and xdg-open from a normal shell opens chromium?

Edit: I just re-read your message and joplin-desktop is what is opening links in chromium -- does that internally use xdg-open?

unode commented 1 year ago

Yes, as far as I can tell joplin-desktop uses xdg-open. I can see it on an strace, however I can't figure out why Firefox isn't launched and Chromium is used instead.

I did however recently have a x-www-browser and symlink www-browser script in PATH that was being executed. Having this script run an arbitrary command worked but having firefox URL in it caused Chromium to launch again.

Right now it looks like, for some reason, Firefox fails to launch and Chromium is used as fallback.

lilyinstarlight commented 1 year ago

I wonder if joplin-desktop is somehow losing the NIXOS_XDG_OPEN_USE_PORTAL environment variable, causing xdg-open to use default logic instead of delegating it to the portal like it's supposed to

unode commented 1 year ago

Ok, a few jumps ahead and it turned out that the version of joplin I had on my environment was bundling an unpatched xdg-open that ignored NIXOS_XDG_OPEN_USE_PORTAL. I thought it was using the system xdg-open but I noticed in strace that it was launching /usr/bin/xdg-open which after inspection pointed to: /nix/store/hr3ks9p076js1r8v4p531nml3k0cqsvb-joplin-desktop-2.8.8-usr-target/bin/xdg-open.

Updated joplin and now Firefox is opening as expected. Confusion mostly cleared though still surprised with the behavior.

@lilyinstarlight Thanks for the help troubleshooting this. Your last comment pointed me in the right direction.

Edit: Perhaps a warning to future readers of this thread. Even though the system's xdg-open may have been patched to use the portal, a bundled xdg-open may still lack the workaround.

huantianad commented 1 year ago

I also was having a similar issue where xdg-open wasn't using my defaults. However, the issue ended up unrelated to this. For some reason, bepinex's doorstop was adding the line "Found UnityPlayer, hooking into it instead" to the start of my .config/mimeapps.list whenever I launched a game with bepinex modding... I've yet to figure out why the heck it's doing this, but I thought I'd mention it in case it helps someone somehow!

LunNova commented 1 year ago

@lilyinstarlight

If not, you may need to make sure XDG_DATA_DIRS+PATH is correctly imported/set for systemd user scope

What's the correct way to do this?

I'm seeing this behavior:

$ nix shell pkgs#glib -c systemd-run --user -t gio mime x-scheme-handler/http
Running as unit: run-u30.service
Press ^] three times within 1s to disconnect TTY.
No default applications for “x-scheme-handler/http”

$ nix shell pkgs#glib -c gio mime x-scheme-handler/http
Default application for “x-scheme-handler/http”: firefox.desktop
Registered applications:
    firefox.desktop
Recommended applications:
    firefox.desktop