XDG portal dialogs not used (Linux)

[shoffmeister]

Issue Type: Bug

vscode does not use the XDG portal dialogs, but "other" dialogs.

This means, for instance, that on an X11 KDE Desktop, the KDE dialogs are not used, but "something else" (apparently GTK / Gnome).

On this very same system, Firefox happily makes use of the XDG portal dialogs.

The screenshot shows Firefox (right) with the "Portal" dialog (see the title bar!); on the left, notice vscode bringing up something different (i.e. not the XDG portal dialog).

Both the installation of vscode and firefox are "native" (i.e. not flatpak, snap or anything) on Fedora 36.

As firefox (and chrome) do the right thing, I suppose the environment is configured correctly; specifically I do have

env | grep -E '(DESKTOP|PORTAL)'

IMSETTINGS_INTEGRATE_DESKTOP=yes
DESKTOP_SESSION=plasmax11
XDG_SESSION_DESKTOP=KDE
XDG_CURRENT_DESKTOP=KDE
CHROME_DESKTOP=code-url-handler.desktop
GTK_USE_PORTAL=1
ORIGINAL_XDG_CURRENT_DESKTOP=KDE

Further, electron is said to have support for this (electron/electron#2911) as of version 14; vscode currently uses electron 17. See also for details at https://tristan.partin.io/blog/2021/04/01/electron-linux-and-your-file-chooser/

VS Code version: Code 1.67.2 (c3511e6, 2022-05-17T18:23:40.286Z)
OS version: Linux x64 5.17.7-300.fc36.x86_64
Restricted Mode: No

[shoffmeister]

Ah, and minutes later it is clear what the problem is:

The author of the electron patch has created a helpful blog entry https://tristan.partin.io/blog/2021/04/01/electron-linux-and-your-file-chooser/ in which he writes: "I open a handle to libgtk-3.so"

The linked commit electron/electron@fa65faa confirms that.

That's all nice and dandy if the Linux installation actually has libgtk-3.so.

Well, Fedora 36 does not have libgtk-3.so. Fedora 36 ships

• /usr/lib64/libgtk-3.so.0.2404.29
• /usr/lib64/libgtk-3.so.0 -> libgtk-3.so.0.2404.29

Solution:

cd /usr/lib64
sudo ln -s libgtk-3.so.0 libgtk-3.so

[shoffmeister]

Request to vscode folks: You are well-connected to electron.

May I kindly ask that you relay the problem with the test for libgtk-3.so to the electron people? I'd think that it would be useful / helpful / good / conservative to also check for libgtk-3.so.0

[shoffmeister]

https://begriffs.com/posts/2021-07-04-shared-libraries.html has some word on .so-versioning:

Standard practice is to create symlinks libfoo.so -> libfoo.so.x -> libfoo.so.x.y.z in a shared system directory. The first link (without the version number) is for linking at build time.

So, according to that, ".so" plain should be expected only at build time, not as delivered on an installed (distribution) Linux. To that extent, the electron patch possibly really should be amended.

[shoffmeister]

FYI electron/electron#31258 on the electron side documents their discovery.

[deepak1556]

Addressed in electron/electron@37b7e34