OS is Silverblue 32
Default, but with this addition to try to make xdg-open open Firefox from within a Flatpak:
exec "dbus-update-activation-environment --systemd DISPLAY MOZ_DBUS_REMOTE"
I also have MOZ_DBUS_REMOTE=1 set in my environment.
flatpak I'd get these errors: Oct 29 12:04:48 localhost.localdomain xdg-desktop-portal[4551]: Error: no DISPLAY environment variable specified
Oct 29 12:05:18 localhost.localdomain xdg-desktop-por[4515]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list
Oct 29 12:09:03 localhost.localdomain xdg-desktop-portal[5368]: Error: no DISPLAY environment variable specified
Oct 29 12:09:06 localhost.localdomain xdg-desktop-portal[5390]: Error: no DISPLAY environment variable specified
It would print a new no DISPLAY... error every time I clicked a URL.
I followed these directions from a related issue in xdg-desktop-portal https://github.com/flatpak/xdg-desktop-portal/issues/285#issuecomment-665109459 which recommended the above dbus-update-activation-environment line.
After that, I no longer got the no DISPLAY environment ... log errors in xdg-desktop-portal.
However, Firefox would still give the dreaded "Firefox not responding ... no profile .. " dialog box.
As was explained by @hadess in https://github.com/flatpak/xdg-desktop-portal/issues/285#issuecomment-719076010 this is because the DISPLAY variable isn't registered by sway at startup, so there is no way to pipe the display through to the flatpak execution context.
Is there another recommended approach to teach my flatpak apps how to launch URLs?
This isn't a Sway bug, Sway has nothing to do with systemd.
@emersion - Thanks for the update.
So what would be the route by which flatpak apps under sway could interact with other components in the system?
Opening URLs from within Flatpak apps works by default in mutter/Gnome, but not in sway. Apparently mutter relies on systemd in order to get the appropriate information into dbus.
How would this be done under sway?
Workaround you found can be used for third-party software that (ab)uses systemd like this.
This isn't a Sway bug, Sway has nothing to do with systemd.
The problem doesn't have anything to do with systemd either. You need a way to pass the DISPLAY variable from sway (which starts XWayland) to the sibling process that starts xdg-desktop-portal (whether it's systemd, or dbus-daemon, or some session helper, it doesn't matter). You don't seem to have that mechanism.
This is an xdg-desktop-portal bug. It relies on being started via systemd or D-Bus activation.
This is an xdg-desktop-portal bug. It relies on being started via systemd or D-Bus activation.
"D-Bus service relies on being started like a D-Bus service" shocker.
Suit yourself.
It's more of a "graphical app works like a D-Bus daemon" shoker.