[Bug]: File dialog overwrites the file manager's "Show hidden files" setting in Linux/GNOME
akilangh opened this issue · comments
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 bug report that matches the one I want to file, without success.
Electron Version
17.4.7
What operating system are you using?
Ubuntu
Operating System Version
Ubuntu 20.04 ( Linux x64 5.13.0-41-generic )
What arch are you using?
x64
Last Known Working Electron version
No response
Expected Behavior
When an Electron based app presents a file open dialog, it should respect the desktop system-wide settings related to visibility of hidden files.
Actual Behavior
Try this on VS Code on GNOME:
- Enable "Show hidden files" in Nautilus.
- Open VS Code's file dialog (for example via Ctrl+O). The hidden files in nautilus will be hidden again
Testcase Gist URL
No response
Additional Information
There is an open bug report for VS Code on this: microsoft/vscode#107246
This issue is present in both KDE and GNOME but it affects GNOME users in a worse way because of a design decision made by GNOME. See microsoft/vscode#151153 for more info on that.
Thanks for looking into this.
There is an Atom bug report too (closed since due to lack of activity): atom/atom#20712
Thanks for reporting this and helping to make Electron better!
Because of time constraints, triaging code with third-party dependencies is usually not feasible for a small team like Electron's.
Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.
Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.
I'm adding the blocked/need-repro label for this reason. After you make a test case, please link to it in a follow-up comment.
Thanks in advance! Your help is appreciated.
@mlaurencin I downloaded Electron Fiddle to see if I can write something small to demo this and noticed something interesting. Fiddle itself suffers from this bug. Since it is Electron's tool I suppose you will be able to reproduce the bug and examine fiddle's code to see where the issue is? I'm copying the steps to reproduce for easy access:
Steps to Reproduce:
- Go to Files (Nautilus) and make sure you can see hidden files (dotfiles) by checking the checkbox under Hamburger Menu -> Show Hidden Files.
- Go to Fiddle
- From menu choose File -> Open...
- Open a file or click cancel.
- Go to Files (Nautilus). You can no longer see hidden files. The checkbox under Hamburger Menu -> Show Hidden Files is now unchecked.
I take it that Fiddle itself is written using Electron?
Hi, do you need anything else from me?
I think this is a relatively simple fix, we need to restore the initial values after the dialog is closed (use gtk_file_chooser_get_show_hidden to get the current value). Or we should check if GTK has an API that only affects the current dialog, not the global state.
See:
electron/shell/browser/ui/file_dialog_gtk.cc
Lines 227 to 228 in c4ea33d
electron/shell/browser/ui/file_dialog_gtk.cc
Lines 236 to 237 in c4ea33d
@mlaurencin Please set assignees to me.
@BlackHole1 Thank you so much. Electron resets the hidden file visibility under KDE too but KDE takes an intelligent approach and changes it only for Electron's file dialog and not anywhere else. I will submit a PR to make Electron obey default desktop settings in KDE too.
we need to restore the initial values after the dialog is closed ... Or we should check if GTK has an API that only affects the current dialog
@BlackHole1 Ideally Electron should not set that value even for its own dialog. User has set a default value in their desktop and Electron should obey that default value. If user needs a different value then user would take appropriate action. That has been my general experience with the apps that I use.
Electron resets the hidden file visibility under KDE too
This should be the expected behavior, since we have showHiddenFiles, see: https://www.electronjs.org/zh/docs/latest/api/dialog#dialogshowopendialogsyncbrowserwindow-options
It might be better to inherit the value of the current system hiddenFiles if showHiddenFiles is not passed in. e.g.
Pseudocode:
gtk_file_chooser_set_show_hidden(file_chooser,
hasProp(SAVE_DIALOG_SHOW_HIDDEN_FILES) || gtk_file_chooser_get_show_hidden(file_chooser))KDE takes an intelligent approach and changes it only for Electron's file dialog and not anywhere else.
This may not be realistic, and based on my investigation today, I've learned that it was intentional. See:
electron/shell/browser/ui/file_dialog_gtk.cc
Lines 193 to 196 in c4ea33d
Sounds like you want to submit a PR for this bug, if so, you're more than welcome to do so! (I'll briefly describe my local fix below, which may help you)
#include <gio/gio.h>
#include <gio/gsettings.h>
// In private:
gboolean show_hidden_files_;
// In void FileChooserDialog::OnFileDialogResponse
// TODO: use `g_settings_schema_source_lookup` check `org.gtk.Settings.FileChooser` exist.
GSettings *settings = g_object_new("org.gtk.Settings.FileChooser");
show_hidden_files_ = g_settings_get_boolean(settings, "show_hidden");
// In ~FileChooserDialog()
// TODO: use `g_settings_schema_source_lookup` check `org.gtk.Settings.FileChooser` exist.
GSettings *settings = g_object_new("org.gtk.Settings.FileChooser");
g_settings_set_boolean(settings, "show_hidden", show_hidden_files_);Inspired by:
The fix code above is only the initial version, and if you are willing to submit a PR for this, I will forgo continuing to optimize this fix and cancel my intention to submit a PR.
If you want to submit a PR, my suggestion is to use: https://github.com/electron/build-tools . This tool will allow you to quickly build electron locally
I will take a look and submit a PR in few days. Thank you!
Confirmed. Looks like every time a GtkFileChooserDefault is unmapped, its settings get saved for next time, e.g. so the system can remember the window position and size of the dialog.
The patch by @BlackHole1 in #34706 (comment) looks like it would solve the immediate problem of not clobbering the show-hidden system setting and would be a good candidate for backporting into the currently-supported versions of Electron. @akilan27 could you give some more information on how the KDE desktop does it differently? Is there something we'd want to do differently from this patch?
Ideally Electron should not set that value even for its own dialog. User has set a default value in their desktop and Electron should obey that default value.
This would be a little better for native integration on Linux, but it will take some work and probably be a semver major change because we'll need to change the Dialog API. The current implementation (in setupOpenPropertiesDialog() in lib/browser/api/dialog.ts) holds bitwise or'ed flags of Dialog.showOpenDialog's options.properties, so in Electron right now the default is all the features in options.properties are off by default and get enabled by explicitly opting in.
To change this:
- We'd need some new C++ code to init the default value from the system preferences, and use that code in
setupOpenPropertiesDialog(). - We'd need to change the public API from 'opt in' to 'override system setting', e.g. under the current API there would be no way in the API to hide hidden files if the system preference is to show them.
@akilan27 ping, do you have any more information about the different behavior in KDE? If so, I'd like to take that into account; but with the information right now I'm inclined to use @BlackHole1's patch to at least solve the issue on GNOME 😸
Sorry about the late reply, life intervened.
The API structure you explained does preclude a quick implementation of my suggestion not to touch system defaults. Unfortunate. I guess at this point @BlackHole1's patch is the best way forward in short term.
As for KDE you don't have to do anything different actually. Under KDE Settings of Electron's file dialog does not affect another app or the system file manager. So, in fact Electron's bug does not affect other apps in KDE. I mentioned KDE only to say that their approach is much better.
The only possible fix for electron is:
Never touch any system wide setting.
That should be fixed now.
The idea to remember the old setting, overwrite the global setting,
and try to restore the setting later is bloated code and also a bug:
That will result in a data race with every program, which reads the setting,
while electron has overwritten the global setting.
No excuse to wait for informations, what KDE is doing.
That's unrelated to this issue.
And not only GNOME suffer from this electron bug,
but every Linux Desktop using GTK.
As a workaround, press 'CTRL' + 'h', when the gtk file dialog is open.
TL;DR
On my system, this setting is saved in:
File: $HOME/.config/gtk-2.0/gtkfilechooser.ini
Section: [Filechooser Settings]
Option: ShowHidden=true
This configuration option is overwritten with:
ShowHidden=false
@winspool That was my original suggestion as well, but if you read the replies from Electron contributors you can see that making Electron stop touching system settings is not a straightforward task due to the API design.
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!
bump
How is this still not fixed yet?
Testing with VSCode 1.76.0, here's a workaround:
-
Make hidden files displayed in the GTK file chooser:
$ dconf write /org/gtk/settings/file-chooser/show-hidden true $ dconf read /org/gtk/settings/file-chooser/show-hidden true -
Open VSCode with the following environment variable:
$ GTK_USE_PORTAL=1 code -
In VSCode, go to File > Open File.
VSCode reads the setting and hidden files are displayed in the file chooser.
@misaki-web Despite it might work (if you have the xdg-desktop-portal package installed -you might have it installed if using Flatpak or Snap-), I doubt it is a good solution.
More on this, looks like GTK_USE_PORTAL env var has been replaced with GDK_DEBUG (see: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829)
Despite it might work (if you have the xdg-desktop-portal package installed -you might have it installed if using Flatpak or Snap-), I doubt it is a good solution.
I agree. It's a quick workaround until an official fix is released, but in the meanwhile, it can be quite useful.
More on this, looks like GTK_USE_PORTAL env var has been replaced with GDK_DEBUG (see: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829)
Yes. The change occurred in GTK 4.7.1, but not in GTK 3.
The workaround could use both variables as follows (example with VSCode; note that it must be run after each software update):
file='/usr/share/applications/code.desktop'
workaround='env GDK_DEBUG=portals GTK_USE_PORTAL=1 '
grep -q "^Exec=$workaround" "$file" || sudo sed -i "s/^Exec=/Exec=$workaround/g" "$file"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!
bump