[BUG] [1.94 Regression] VS Code uses the wrong, deprecated file/folder picker on Gnome.

[103sbavert]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version/OS version:

Version: 1.94.2
Release: 24284
Commit: ea88724571c2cd4044155127c5ba85681e5cdcfe
Date: 2024-10-10T18:23:57.145Z
Electron: 30.5.1
ElectronBuildId: undefined
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: 12.4.254.20-electron.0
OS: Linux x64 6.11.2-zen1-1-zen
Desktop Environment: Gnome 47

Steps to Reproduce:

1. Open a new VS Code window
2. Click on "Open folder" from the primary sidebar.

Expected:

VS Code opens the default Nautilus file explorer that it used to show priot to 1.94 update (see screenshot).

Actual observation:
VS Code opens the GTK file explorer that is deprecated on Gnome in favor of the native file chooser

Additional information:
Prior to Gnome 47, the difference between the GTK file chooser and the nautilus file chooser was minimal. But since 47, the Gnome team has made massive improvements to the default file chooser which used to open perfectly correctly before the September 1.94 update.

[deepak1556]

Between 1.93 and 1.94 there is an increase in the required portal version to support defaultPath feature. Otherwise users will face the following issue #213780

There isn't a release of xdg-desktop-portals yet that covers the feature, so the older gtk based dialogs will be used till then. electron/electron#43819 (comment) has additional context

[lucassith]

It happens for me as well, and I'm not using gnome but KDE.

It is enough just to click on "File" for VSCode to crash.
I'm using Arch Linux with Code built aur build.

It started happening after last update of the desktop environment.

[drankinatty]

In response to your request on the now closed file-open dialog bug, here is the output with --verbose --vmodule=*/ui/*=2 added.

[main 2024-11-16T08:56:49.547Z] [DialogMainService]: request to acquire file dialog lock {
  title: 'Open File',
  buttonLabel: undefined,
  filters: undefined,
  defaultPath: '/home/david/dev/embedded-rpz/rpz/tst/gpio_v2_ir_snsr',
  properties: [ 'multiSelections', 'openFile', 'createDirectory' ]
}
[main 2024-11-16T08:56:49.548Z] [DialogMainService]: new file dialog lock created {
  title: 'Open File',
  buttonLabel: undefined,
  filters: undefined,
  defaultPath: '/home/david/dev/embedded-rpz/rpz/tst/gpio_v2_ir_snsr',
  properties: [ 'multiSelections', 'openFile', 'createDirectory' ]
}
[59032:1116/025649.577047:VERBOSE1:select_file_dialog_linux_kde.cc(425)] KDialog command line: kdialog --attach=31457283 --title=Open File --multiple --separate-output --getopenfilename /home/david/dev/embedded-rpz/rpz/tst/gpio_v2_ir_snsr
[59032:1116/025649.600484:VERBOSE1:select_file_dialog_linux_kde.cc(568)] [kdialog] MultiFileResponse:
[main 2024-11-16T08:56:49.600Z] [DialogMainService]: file dialog lock disposed {
  title: 'Open File',
  buttonLabel: undefined,
  filters: undefined,
  defaultPath: '/home/david/dev/embedded-rpz/rpz/tst/gpio_v2_ir_snsr',
  properties: [ 'multiSelections', 'openFile', 'createDirectory' ]
}
[main 2024-11-16T08:56:57.269Z] Lifecycle#window.on('close') - window ID 1
[main 2024-11-16T08:56:57.270Z] Lifecycle#unload() - window ID 1

There is no file-dialog generated. It seems from the above it tries, but immediately closes the window before it is ever displayed. Hope this helps get it fixed.

[ShwStone]

On my archlinux kde6 wayland, this problem is solved by installing kdialog.

[venteto]

It seemed like this problem had gone away for me, but I must've just gotten a VS Code and/or Electron upgrade in the last few days because now this is broken again (as is my Paste keyboard shortcut, but I digress) ... now using Code - OSS 1.96.4 on Manjaro Linux with GNOME 47.3 ... I don't seem to have a --vmodule flag anymore either, when attempting generate the terminal output mentioned in the reply above by @drankinatty

I feel like I need to start blocking upgrades to both VS Code and Electron after these ongoing cycles of fundamental things breaking, maybe even go back to using Sublime Text, as (I think?) it doesn't seem to depend on Electron