KDE File Dialogs Don't Load in Firefox with GTK_USE_PORTAL=1 environment variable with xdg-desktop-portal-kde 5.18.3

It is working in my arch test system.

I wonder if something is slightly out of sync on whatever branch you are on.

Here are some perhaps relevant versions on that machine:

local/xdg-dbus-proxy 0.1.2-1
local/xdg-desktop-portal 1.6.0-2
local/xdg-desktop-portal-kde 5.18.3-1
local/dbus 1.12.16-5
local/plasma-desktop 5.18.3-1 

Or something is just not in the right place (ie in the path), or missing (not installed), etc.
You will also need installed:
The Plasma-browser-integration package
The Plasma Integration extension from Firefox addons.
export GTK_USE_PORTAL=1 via script, I use /etc/profile.d/xdg-dektop-portal-kde.sh

You also should not have both xdg-desktop-portal-kde, and xdg-desktop-portal-gtk installed at the same time, this typically will not work as these will conflict with each other.

@freggel.doe
AFAIK, GTK_USE_PORTAL=0 shouldn't do anything.

Sure it does: it alters the currently preset value coming via manjaro-kde-settings-19.0 package so that Firefox is usable at all (on testing).
If this variable wasn't set in the first place one wouldn't need it.

1 Like

I just checked my testing machine, and it does not have this issue.
The only mention I've found to a similar issue, was in the KDE, and Gentoo bug trackers, that effected Gentoo, and was ultimately caused by a Gentoo patch. AFAIK, we don't use Gentoo patches.

Please, show me any reference online, or any documentation for that matter, for GTK_USE_PORTAL=0 as an actually supported setting.

Does it have manjaro-kde-settings-19.0 installed or GTK_USE_PORTAL environment variable set by any other means?

I can't even find any "official" documentation that GTK_USE_PORTAL=1 would be a valid value.
On my system the issue is showing and get's fixed when starting firefox via

$ GTK_USE_PORTAL=0 firefox

Unsetting the variable should do as well.

i notice that i have manjaro-kde-settings (without -19) installed and it works for me.
i also haven't set the ENV globally but changed my firefox.desktop to Exec=/usr/bin/sh -c "GTK_USE_PORTAL=1 /usr/lib/firefox/firefox %u"

Yes it does, however I did add the /etc/xdg/plasma-workspace/env/envars.sh file myself manually.
The manjaro-kde-settings-19.0 package is not available in the arm repositories.
All other relevant packages are available, and installed, as is the plasma integration extension through the Firefox add-on store.

This is a rpi4b 4 gig, with a 128 gig sd card, running on the Manjaro arm rpi4 edition.

Here are the screen shots:
Screenshot_20200313_044952

Screenshot_20200313_045508

So unless one, or more packages, are not compiled, and/or setup correctly on x86_64, I'd say something locally has to be wrong (ie. missing packages, missing firefox add-on, home directory is sandboxed, incompatible theme, conflicting settings, and/or settings files, etc.).

I have plasma-browser-integration, xdg-desktop-portal and xdg-desktop-portal-kde installed.

I'm using the Plasma Integration addon.

Not using that.

Default breath2 theme.

Didn't investigate further, it's still on the table as a possibility.

I did see an additional warning in journal regarding a missing library, that wasn't visible on systemctl status --user xdg-desktop-portal (like I mentioned on my testinng announcement reply):

Mär 13 07:50:44 jupiter org.freedesktop.impl.portal.desktop.kde[10129]: /usr/lib/xdg-desktop-portal-kde: error while loading shared libraries: libpipewire-0.3.so.0: cannot open shared object file: No such file or or directory
Mär 13 07:50:44 jupiter xdg-desktop-por[9861]: Failed to create screen cast proxy: Fehler beim Aufruf von StartServiceByName für org.freedesktop.impl.portal.desktop.kde: Process org.freedesktop.impl.portal.desktop.kde exited with status 127
Mär 13 07:50:44 jupiter xdg-desktop-por[9861]: No skeleton to export

Switching to unstable has fixed the issue for me without any further adjustments.

You also need the plasma-browser-integration package installed, this is not the same things as the add-on.

It is, I've edited my post accordingly.

Like I said, unless there is something compiled wrong in the x86_64 testing branch.
Another possibility is one or more of these packages were compiled against the wrong version of something else, and this is fixed again in unstable. IDK, my intel machines are either on stable, or running Enlightenment.

libpipewire-0.3.so.0 certainly isn't available on testing and could be at the root of it all.

I didn't even think about the pipewire package, it is a dependency for portals to function.
But then, it could be any of the dependencies for this that are in a mismatched state.

There is a not-so-recent update to xdg-desktop-portal from Arch Linux and that fixes this issue but it also requires pipewire to be upgraded to 0.3.1-1 which is not on testing yet. Using downgrade from AUR to (ironically) upgrade those packages fixes the issue.

Also as a side note, xdg-desktop-portal pushes a new release (1.7.0) a few hours ago and that release now requires pipewire 0.3.

On testing the only thing we need is pipewire 3 because the xdg-desktop-portal-kde is looking for it, failing badly :slight_smile:

/usr/lib/xdg-desktop-portal-kde: error while loading shared libraries: libpipewire-0.3.so.0: cannot open shared object file: No such file or directory

So... how to get that version of pipewire on testing?

Switch branches to unstable and update.
Or with:

sudo pacman -U https://manjaro.moson.eu/unstable/extra/x86_64/pipewire-0.3.1-1-x86_64.pkg.tar.zst

but you will also have to

sudo pacman -U https://manjaro.moson.eu/unstable/extra/x86_64/libpipewire02-0.2.7-1-x86_64.pkg.tar.zst

Make sure you have the:
export GTK_USE_PORTAL=1
in /etc/profile.d/mozilla-common.sh or whatever approach of this you prefer from those mentioned ... then reboot the system. FF will have the native KDE Plasma file dialog.

1 Like

The proper way to unset this environment variable when launching firefox from a terminal is not to set GTK_USE_PORTAL=0

This is the correct way:

env --unset=GTK_USE_PORTAL /usr/bin/firefox

This issue has been fixed in the Testing Update from yesterday.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by