Change:
"cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "17.4.6", </del> <ins> "electron": "17.4.7", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^19.1.0",

Discussion:
System: Red Hat Enterprise Linux Workstation release 7.9 (Maipo) OS: Linux myhost 3.10.0-1160.36.2.el7.x8664 SMP Thu Jul 8 02:53:40 UTC 2021 x8664 x8664 x8664 GNU/Linux This began as an occasional annoyance and has escalated into a 100% reproducible annoyance. Using the latest snap install, during normal editing/debugging/etc. on local system. With increasing frequency, Ctrl-O/File-Open would completely freeze the UI with just a blinking cursor. Sometimes switching away and back would repaint part of the screen, increasingly not. Tried switching the output window to various things before attempting the file open (extension manager, main window, etc), but no output was observed before the freeze. Once the UI is frozen, only kill/killall seems to be able to get rid of it. Not sure if it means anything, but de-maximize and maximize still resize the window frame, although the contents aren't redrawn. Can't remember if that requires app cooperation or it that is a pure WM thing. Using snap installed code-insiders made no difference. Uninstalling snap versions and downloading 1.65.0 from the MS repo so far seems to have restored functionality (1.66.0 requires a glibc version unavailable for RHEL7). Haven't tried with (all) extensions disabled, but did disable everything I don't need constantly. One change in workflow recently seems suspiciously coordinated with the start of the issues - began using VS Code on another machine (nfs-mounted home folder, so shared settings/etc.) to attach to running containers (as container-specific user, to specific folder inside container), debug processes inside container, etc. Perhaps something got saved in the settings that is redirecting local File-Open to the remote-containers extension? Probably not, but the timing is mighty suspicious.
Interesting. With 1.65.0 still running, snap installed the latest (1.66.0) again and ran it with: Ctrl-O still hung the 1.66.0 app. Apparently it isn't an extension.

me is the same vscode is really disgusting
yes, I ran into the same problem, vscode hangs when execute any open command, open folder or open a file
Same for me on my Ubuntu 18.04 :-( Installed via tail of :
Also happening here, is there any known workaround at the moment to still open a folder? (Also seems to be related)
points to mismatched gtk library version loaded in the app process or others facing the issue, can you please follow the steps below and attach the generated profile
Thanks! Attached as requested above.
Is the log cut off ? I don't see most the library loads that are required for startup.
hmm, sorry, would be sufficient ? Because that is an only single output which I've got after execution. p.s. I am using managed PC and don't have permissions for :-(
In the past when I tried strace directly with snap packages and it would fail, hence I rely on the flag. Not sure if it works better now. No worries, I hope others hitting this issue might be able to provide the required trace. In the meantime, can you check if the issue exists with our debian package ?
Debian package works well (with some strange behavior). Thanks for a temporary solution. Strange behavior -maybe because I've disconnected all my monitors, but Open Folder dialog opens in background, thus I have to bring it manually to the foreground (but it is better than hanging program anyway ;-))
Here is the log I have with the instruction
I am also having this problem with the latest update (though I never had the application hanging problem) on Ubuntu 18.04
Thanks for the log, it confirms the root issue. Snap bundle ships with a version of libgtk3 that gets loaded by the app for all gtk operations, can be seen with With Electron 14 there was a refactor in the file dialog implementation to support XDG portal specification and the gtk library that was trying to be loaded as part of this is not bundled within the snap and in which case will search the system library paths, if the library cannot be found then the old code path will be utilized that will use the alreaedy loaded gtk library in the process but incases where it is found from the system and gets loaded, if the version mismatches with the already loaded library in the process, it causes the above app freeze.

This should be fixed in Electron to use the same calls as chromium ;l=79-82? to load the gtk library.
so how should we solver it ?
I've got the exact same problem. So, if this has been fixed in Electron 18 when can we expect an update to VSCode? Because I'm on 1.67.1 and the error still persists.
This issue is very annoying: ! Hope upgrade to electron18 as soon as possible
This issue started for me after installing . Not sure if that is helpful? After removing this package (and also running afterwards), the issue was gone.
Got the newest version; but same error... Commit: Date: 2022-05-17T18:23:40.286Z Electron: 17.4.1 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Linux x64 4.15.0-177-generic snap
Update to Electron 18 is gonna take a bit longer, I will try to get the fix into Electron 17 as well. The issue is not yet addressed in our insiders and stable.
Latest version (from 2 days ago) still has the same bug (Ubuntu 18.04). Does anyone have a workaround? Any way to install an older version? EDIT: Downloading the Linux 64 .deb from solved the issue for me.
if you're just looking for a workaround, try the terminal command: or . It work's for me at least. But for a more solution maybe 's helps (I haven't tried it myself).
Same issue. Ubuntu 18.04. Channel: latest/stable: 2022-05-18 (97). thank you for the workaround. Removed new snap version and installed 1.65.0. Solved for me.
I was having a similar issue with vscode 1.67.2, non-snap on Ubuntu 20.04. After I noticed the issue I tried an apt upgrade, which didn't fix it. Downgrading to 1.65.2 fixed it for me. I am using i3 for window management.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of !

you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Verification Steps: Install Ubuntu 18.04, images available from Install gtk3 <= 3.22, Install stable vscode from snap, Launch code and open the file explorer Verify application freezes Install insiders from snap, Launch code-insiders and open the file explorer Verify file explorer launches and application does not hang
can you help in verifying this since you have Ubuntu 18.04?
Hey , I can confirm that I get a dialog with the same setup and . Thanks! p.s. nevertheless, the strange behavior of dialog appearing in background remains the same as for previous solution using - but that is fine for now.