@codebytere also noticed https://issues.chromium.org/issues/41469294#comment10, which says that upstream likely wants to support GtkFileChooserNative on GTK4

I have automatically backported this PR to "31-x-y", please check out #42109

I have automatically backported this PR to "30-x-y", please check out #42110

@codebytere has manually backported this PR to "29-x-y", please check out #42144

If this is the change where you search for command line utilities to use as your file-chooser, like kdialog, etc.., this breaks fileChoose display on Trinity Desktop Environment TDE/KDE3. It further breaks any chooser where multiple versions of a chooser like kdialog are installed and the $PATH ordering places the older first.

Any fileChooser scheme should not depend on how the $PATH variable may or may not be set and should not utilize command-line utilities to generate fileChoosers without validating the version of the utility and whether or not it supports the options it is sent. Ultimately, this breakage is one of basic validation and providing a fallback that was not done in this change. If the fileChooser selected does not display and instead throws an error, then that needs to be handled and the default Gtk choosers need to be shown as they were up until vscode ver: 1.89.

See the bug linked by @daiyam above Linux - vscodium no longer displayes the file-dialog after update to Ver. 1.9.0. This affects more than just TDE/KDE3 as noted by the comments in that bug report. It also effects vscode/vscodium identically. Several work-arounds (ugly hacks) are included in the linked report that either involve intercepting the call to the command-line utility and rewriting the command or to alter the $PATH to remove the search-path to the utility forcing the use of the normal Gtk dialogs. Neither are realistic.

It may be convenient to simply search the Linux PATH for a set of executable names to use as fileChoosers, but there is no telling what you actually find. So there needs to be additional validation that the fileChoose found is actually what you think it is, and if not, provide the Gtk fallback.

Lastly, there needs to be a clear way to disable this new behavior and restore the default Gtk dialogs on desktop that this breaks fileChooser display on. Mozilla provides widget.use-xdg-desktop-portal.file-picker which when set to 0 disables searching for native chooser utilities and restores default Gtk dialog use. Something like that in the vscode preferences would work, or a command line option. Because, above all, a New Feature to one, is a BUG to another -- if it cannot be turned off.

Hopefully the behavior of this commit can be made more robust to prevent the dialog failures it causes. Absent that a clear option to disable it and restore default dialogs would be greatly appreciated.