[Bug]: Improve Linux XDG FileChooser implementation

[vchernin]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Electron Version

14.0.0

What operating system are you using?

Other Linux

Operating System Version

Linux any

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

Support for the XDG FileChooser portal landed in Electron 14 #19159.
Electron should try to use the XDG FileChooser wherever it can.

Actual Behavior

There are cases where it is not used where it could be used (specifically on Ubuntu and in Flatpak, see below). The old non portal file chooser is used, meaning the work in #19159 is not taken advantage of.

Testcase Gist URL

No response

Additional Information

Any help on how to debug Electron here would be appreciated, as I’m not sure why this is happening.

See discussion on what likely is a symptom of this issue:
squalou/google-chat-linux#38 flathub/com.mattermost.Desktop#39

This is not a regression. Worst case the old file chooser will be used, but that’s what’s been the behaviour for years anyway.

[prozaiczyk]

X

[MurzNN]

Same problem for me on various Ubuntu systems with Electron 14 and 15, even with forcing GTK_USE_PORTAL=1 I still see old GTK file dialogs instead of native KDE, but on same system Firefox with GTK_USE_PORTAL=1 shows the KDE file dialogs, so seems in Electron the xdg portals are detected wrongly?

[ilya-zlobintsev]

The XDG Picker seems to work properly for me on Arch Linux with the discord_arch_electron package and GTK_USE_PORTAL=1 set.

[tristan957]

Keep in mind your system has to have a recent enough version of GTK3. I think >= 3.20. One way to double check if you are getting the XDG picker is to watch dbus calls on your system. You are looking for something along the lines of org.freedesktop.Portal.FileChooser

[MurzNN]

My Ubuntu have 3.24.25 version of GTK, and here is dbus call that I caught on file save event in app (Ferdi with Electron 15.2.0):

method call time=1634390665.793665 sender=:1.722 -> destination=org.freedesktop.DBus serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',interface='ca.desrt.dconf.Writer',path='/ca/desrt/dconf/Writer/user',arg0path='/org/gtk/settings/file-chooser/'"
method return time=1634390665.793693 sender=org.freedesktop.DBus -> destination=:1.722 serial=6 reply_serial=10

But still see the GTK file chooser.

And here is dbus call when opening file save dialog in Firefox:

method call time=1634390846.000020 sender=:1.713 -> destination=:1.717 serial=156 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.impl.portal.FileChooser; member=SaveFile
   object path "/org/freedesktop/portal/desktop/request/1_681/gtk1224905431"
   string ""
   string "x11:5e0002c"
   string "Save As"
   array [
      dict entry(
         string "modal"
         variant             boolean true
      )
      dict entry(
         string "filters"
         variant             array [
               struct {
                  string "Web Page, complete"
                  array [
                     struct {
                        uint32 0
                        string "*.[hH][tT][mM]"
                     }
                     struct {
                        uint32 0
                        string "*.[hH][tT][mM][lL]"
                     }
                  ]
               }
               struct {
                  string "Web Page, HTML only"
                  array [
                     struct {
                        uint32 0
                        string "*.[hH][tT][mM]"
                     }
                     struct {
                        uint32 0
                        string "*.[hH][tT][mM][lL]"
                     }
                  ]
               }
               struct {
                  string "Text Files"
                  array [
                     struct {
                        uint32 0
                        string "*.[tT][xX][tT]"
                     }
                     struct {
                        uint32 0
                        string "*.[tT][eE][xX][tT]"
                     }
                  ]
               }
               struct {
                  string "All Files"
                  array [
                     struct {
                        uint32 0
                        string "*"
                     }
                  ]
               }
            ]
      )
      dict entry(
         string "current_filter"
         variant             struct {
               string "All Files"
               array [
                  struct {
                     uint32 0
                     string "*"
                  }
               ]
            }
      )
      dict entry(
         string "current_name"
         variant             string "webpage.html"
      )
      dict entry(
         string "current_folder"
         variant             array of bytes "/home/murz-local/!temp" + \0
      )
   ]
method return time=1634390846.001891 sender=:1.713 -> destination=:1.681 serial=157 reply_serial=121

[MurzNN]

And here is the dbus call on zenity --file-selection cli command, that opens KDE choose file dialog as result:

method call time=1634391265.992642 sender=:1.713 -> destination=:1.717 serial=187 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.impl.portal.FileChooser; member=OpenFile
   object path "/org/freedesktop/portal/desktop/request/1_755/gtk338803498"
   string ""
   string ""
   string ""
   array [
      dict entry(
         string "accept_label"
         variant             string "_ОК"
      )
      dict entry(
         string "modal"
         variant             boolean false
      )
      dict entry(
         string "multiple"
         variant             boolean false
      )
      dict entry(
         string "directory"
         variant             boolean false
      )
      dict entry(
         string "filters"
         variant             array [
            ]
      )
   ]
method return time=1634391265.993344 sender=:1.713 -> destination=:1.755 serial=188 reply_serial=2
   object path "/org/freedesktop/portal/desktop/request/1_755/gtk338803498"

[vchernin]

Hm, @tristan957 I noticed on Electron 16 while testing Jitsi Meet (Flatpak) and this demo (toolbox), it seems the portal works reliably now? I can clearly see the calls in Bustle, and within Flatpak I can choose beyond the sandbox. Even without GTK_USE_PORTAL=1 it's still using the portal.

So that's something I guess.

[tristan957]

Hey that is awesome. Not sure what would have changed beyond that PR last week.

[vchernin]

Yeah me neither, hopefully other apps update soon to 16 so it can be confirmed to work.

[tristan957]

VSCode is working on it, but there are still a couple of blockers. Will be cool when it does.

[vchernin]

Yeah VScode will be interesting, although I'm not sure how useful the portal will be for them given flatpak/xdg-desktop-portal#463 and flatpak/xdg-desktop-portal#663 exists. Wouldn't an IDE need permanent access to a whole directory?

[tristan957]

I would think the VSCode flatpak has filesystem=host permissions. VSCode mainly just wants ability to pick file chooser at the moment.

[vchernin]

Yeah, hopefully eventually they can move away from those static filesystem permissions once/if the portal covers all their use cases.

[ghost]

The document portal can be used to get access to directories with a file chooser already. What’s missing is things like knowing the real path of the file or directory (flatpak/xdg-desktop-portal#475) and getting properly notified when files are changed by another program (flatpak/xdg-desktop-portal#567).

[ssokolow]

@shimmark You really consider it optimal to force a two-stage "Pick a directory, now use our proprietary picker to pick a file within it" workflow on people for something like a directory fully of .mp4+.srt or .cue+.bin pairs?

...assuming the application developer will even be willing to support something like that, rather than just declaring tighter sandboxing an unsupported configuration.

(Or are you one of those people who actually likes iOS/iTunes-style "everything has its own library browser and that's how you interact with what it supports" UI design?)

Bear in mind that I'm far enough on the opposite end of the spectrum that I whipped up a proof of concept that generates non-reverse-DNS launcher wrappers for Flatpak'd applications so I can type mpv ... in the terminal and have it expand to flatpak run --file-forwarding "io.mpv.Mpv/x86_64/stable" @@u "$@" @@.

EDIT: Ignore this. I thought the previous message was something on flatpak/xdg-desktop-portal#463 that was arguing against it being necessary.

[ghost]

No, I don’t consider that optimal! My list of things missing wasn’t meant to be exhaustive. What you’re asking for is flatpak/xdg-desktop-portal#463.

Though there are also editors that expect to have access to .editorconfig and .git in parent folders when opening a single file, and a portal that merely allows opening neighbouring files wouldn’t be enough for that (since .editorconfig and .git could be in parent folders rather than the same folder). So some cases might still require having the user select a directory rather than a file, even when they’d prefer to select only a file.

[ssokolow]

@shimmark Oops. Sorry. I got about half a dozen message notifications at the same time, got mixed up, and thought this was flatpak/xdg-desktop-portal#463.

[opl-]

I figured out a solution which works for me after brief two hours of confusion.

#19159 tries to be safe in how it depends on libgtk by loading it dynamically and trying to find the dialog related functions dynamically. It does this by requesting a file called libgtk-3.so:

https://github.com/tristan957/electron/blob/25b540187140463a4d0f9908bccc8606d2693bb4/shell/browser/ui/file_dialog_gtk.cc#L75

Debian, meanwhile, packages libgtk as libgtk-3.so.0:

$ dpkg -L libgtk-3-0:amd64
...
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
...

As a workaround, I linked the library (which seems to be common practice with sonames, but is for some reason applied very inconsistently by repository maintainers):

sudo ln /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 /usr/lib/x86_64-linux-gnu/libgtk-3.so

Restarting the electron application and triggering a file picker again confirmed that this was the issue.

(As an aside, the KDE file picker appeared behind the electron application which hints at an extra issue here. Setting a window override for window class xdg-desktop-portal-kde to force no focus stealing prevention fixed this, which makes me think this might caused by the parent window not being set?)

[shoffmeister]

Fedora 36 does not ship libgtk-3.so either; creating it via softlink to libgtk-3.so.0 unbreaks the electron functionality.

[MurzNN]

Fedora 36 does not ship libgtk-3.so either; creating it via softlink to libgtk-3.so.0 unbreaks the electron functionality.

For Ubuntu this trick works too, thanks!

sudo ln -s /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 /usr/lib/x86_64-linux-gnu/libgtk-3.so

So maybe we can improve this on Electron side, to detect .0 and other more precise versions of libraray?

[shoffmeister]

It seems to have been addressed already (indirectly) by way of 37b7e34 which came as part of #33650

That PR basically flipped to different dynamic referencing to shared library code that is known to be working for Chrome. Chrome shows the portal dialogs, so knows how to correctly get hold of the GTK native dialogs.

As far as I can tell (from the git branches), this has been on electron since version 18.

[damnms]

for those on fedora (36), too lazy to read all that:
sudo ln /usr/lib64/libgtk-3.so.0 /usr/lib64/libgtk-3.so

at least that worked for me to upload files in element, thanks!

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[github-actions]

This issue has been closed due to inactivity, and will not be monitored. If this is a bug and you can reproduce this issue on a supported version of Electron please open a new issue and include instructions for reproducing the issue.