"No Apps available" when clicking a URL

[betaRadiation]

When clicking a url in any application besides my web-browser a windows pops up with the name Open With... with the text No Apps available, No apps installed that can open "https://google.com". You can find more applications in Software. There is a button that tries to open gnome software which doesn't work because I do not have it installed.

The default application for x-scheme-handler/https is librewolf.desktop which I confirmed with these commands:

> xdg-mime query default x-scheme-handler/https ibrewolf.desktop

> gio mime x-scheme-handler/https Default application for “x-scheme-handler/https”: librewolf.desktop Registered applications: librewolf.desktop Recommended applications: librewolf.desktop

I am confused why it opens this window instead of librewolf.

[sagehane]

I have the same issue on RiverWM with NixOS for Flatpak applications.

$ xdg-mime query default x-scheme-handler/https
org.mozilla.firefox.desktop

$ gio mime x-scheme-handler/https
Default application for “x-scheme-handler/https”: org.mozilla.firefox.desktop
Registered applications:
    org.mozilla.firefox.desktop
Recommended applications:
    org.mozilla.firefox.desktop

xdg-open "https://www.example.com" and similar works fine but clicking on a link inside any Flatpak application causes the issue.

River info

I'm on https://github.com/riverwm/river/commit/7f30c655c75568ae331ed0243578d91870f3f9c6.

Relevant config for ~/.config/river/init:

#!/bin/sh

# https://github.com/emersion/xdg-desktop-portal-wlr#running
dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP=wlroots

<omitted>

NixOS Info

$ nixos-version 
23.11.20230927.8a86b98 (Tapir)

Relevant config:

  services.flatpak.enable = true;
  xdg.portal = {
    enable = true;
    wlr.enable = true;
    # https://github.com/emersion/xdg-desktop-portal-wlr/issues/42
    extraPortals = with pkgs; [xdg-desktop-portal-gtk];
    # Breaks `xdg-open` by causing the same behaviour as opening links from Flatpak
    #xdgOpenUsePortal = true;
  };

[TingPing]

@sagehane Is it possible you are missing XDG_DATA_DIRS in your dbus environment? Because all this portal does is functionally identical to gio mime ....

[anatosun]

I have the same issue with xdg-desktop-portal-gtk version 1.14.1-3 on SwayWM version 1.8.1 and kernel 6.5.5.

[xz-dev]

I have the same issue at Gentoo, also see issues link

[Brisingr05]

Start Sway with the following command: dbus-run-session sway

[OpenBagTwo]

I'm experiencing the same issue on Arch running the Pantheon desktop environment (Gala WM):

• gala 7.1.2-2
• pantheon-session 6.0.0-4
• xdg-desktop-portal 1.18.0-2
• xdg-desktop-portal-gtk 1.15.1-1

[Brisingr05]

@sagehane I'm on NixOS as well and was able fix this by running the following commands:

systemctl --user import-environment PATH
systemctl --user restart xdg-desktop-portal.service

More info here. Also, as mentioned in my previous comment, I was starting my session with dbus-run-session, but I was having issues with distrobox. That method could still work for others, including non-NixOS users, since that method worked on Fedora as well.

[sagehane]

@Brisingr05, I can confirm that xdg-open works after doing what you said. Thanks.

[lasumn]

@Brisingr05 that fixed it.

[smcv]

xdg-desktop-portal and xdg-desktop-portal-gtk are activatable D-Bus services. This means that they inherit environment variables from the "activation environment" maintained by either systemd --user (if you use systemd) or dbus-daemon (if you don't). They do not inherit environment variables from your GUI environment or from your shell, unless some component of the overall system takes responsibility for taking the necessary environment variables from your GUI environment and asking systemd or dbus-daemon to add them to the activation environment.

In a well-integrated desktop environment like GNOME, KDE Plasma or similar, or in a well-integrated operating system, either the GUI environment or the OS vendor will generally arrange for the activation environment to contain a suitable PATH, XDG_DATA_DIRS, DISPLAY, WAYLAND_DISPLAY and so on, so that components like these can work as intended.

In GUI environments that you are expected to build yourself out of individual components (such as Sway), or in operating systems that expect you to build your own working system out of individual components, this integration is often not done automatically. Instead, you are the system integrator. The benefit of this is that you have absolute control over pretty much everything. The cost of this is that you are required to set up a working system for yourself, because nobody else has taken responsibility for doing it for you.

xdg-desktop-portal (and its backends like xdg-desktop-portal-gtk) will not work correctly if the necessary system integration has not been done. It can either be done by your GUI environment vendor, or by your OS vendor, or by you personally, but someone has to do it.

(I personally prefer to use a well-integrated desktop environment on a well-integrated operating system, even if that means sacrificing a small amount of flexibility and control for the sake of having things work automatically; but opinions vary, and some people put a higher value on having everything precisely the way they want it.)

We don't have enough information on this issue to know for sure that @betaRadiation was in the same situation as other commenters, but in the absence of any replies from them since 2023, I'm going to assume that this was the case.

[janvhs]

If you run into this problem just now, check if gio mime x-scheme-handler/https is set to the application's desktop file you desire. Mine was unset even though xdg-mime query default x-scheme-handler/https yielded org.mozilla.firefox. This fixed it for me.

If you are on Arch Linux, it handles the environment variables setup and dbus activation automatically via this file. If you are not on systemd, you might need to do this.

You can start sway whatever way you fancy. I just start it via typing sway in the terminal. Just make sure you update the dbus environment and systemd user environment if applicable