"Open/Save File" Dialog behind main window on Linux

[playgithub]

Env

• OS: Manjaro
• Desktop: KDE Plasma 5.24.5
• VSCodium: 1.68.0 (BTW the previous version also has the same problem)

Problem

When opeing or saving a file, if a file name is needed, the popup file dialog is behind the main window instead of in front of the main window. So the file dialog needs to be bring to front manually everytime.

More Info

Not tested for vscode, because it's not convenient to test it on Manjaro.

[jocot]

confirmed on ubuntu 20.04.4 LTS / Gnome desktop I get a notification saying "Save As" is ready, and have to alt-tab to the view save file dialog. This behaviour started appearing sometime in the last handful of updates.

Version: 1.69.2 Commit: 3b889b090b5ad5793f524b5d1d39fda662b96a2a Date: 2022-07-19T00:58:08.152Z Electron: 18.3.5 Chromium: 100.0.4896.160 Node.js: 16.13.2 V8: 10.0.139.17-electron.0 OS: Linux x64 5.4.0-122-generic

[playgithub]

Still true in 1.70.0

[javiergcim]

Still true in 1.71.0

[daiyam]

Seems to be an electron bug: https://github.com/electron/electron/issues/32857

[CarterSnich]

1.72.2, bug still exists on Manjaro KDE 5.25.5. I just installed vscodium. I used vscode from AUR before and the Open/Save file dialog works perfectly fine.

[Riddle1001]

Adding https://extensions.gnome.org/extension/2182/noannoyance/ to get rid of the top pop up notification worked for me.

[Crystal-RainSlide]

1.72.2, bug still exists on Manjaro KDE 5.25.5. I just installed vscodium. I used vscode from AUR before and the Open/Save file dialog works perfectly fine.

Could be some closed source patch from Microsoft applied on VSCode's Electron, or, either Manjaro or KDE did something to VSCode.

Update: From https://github.com/microsoft/vscode/issues/146422 , seems that it's not Microsoft.

[CarterSnich]

I think that gnome tweaks won't do much help on KDE. But, I found a way to fix this. File dialog now popup over the main vscodium window and prevents me to click on it.

EDIT: One small issue. This method makes the file dialog tops over all other windows.

[mramendi]

Same problem here. Fedora 36, KDE Plasma 5.26.4, VSCodium 1.74.0

[weefunker]

Same problem for months now, especially annoying in vscode

Ubuntu 20.04.5 LTS

[nurettin]

I don't know if this is related, but every time I try saving an unsaved new file, the save-as dialog freezes with 100% CPU usage.

[mrflos]

This worked for me but I had to use as window class xdg-desktop-portal-gtk

[stotes]

@mrflos suggestion partially worked for me however it would set all windows above others which isn't the desired result.

The following settings worked better for me running 6.1.12-1-MANJARO Plasma

Window Class: codium Window Type: dialog Window Role [Exact Match]: gtkfilechooserdialog

Add Property... Keep above other windows -> [Force] -> Yes

---

[drajathasan]

@mrflos suggestion partially worked for me however it would set all windows above others which isn't the desired result.

The following settings worked better for me running 6.1.12-1-MANJARO Plasma

Window Class: codium

Window Type: dialog Window Role [Exact Match]: gtkfilechooserdialog

Add Property... Keep above other windows -> [Force] -> Yes

Any suggestion for non KDE? I use Mate.

[stotes]

@drajathasan I've never used mint so I can't say if this will work, however I would suggest you investigate the CCSM "Window Rules" plugin. http://wiki.compiz.org/WindowMatching#Window_Rules

[drajathasan]

@stotes thanks.

[playgithub]

electron bug: https://github.com/electron/electron/issues/32857

[securegh]

Is there any solution to this? I have the same issue here:

Operating System: Zorin OS 16.2 Kernel: Linux 5.15.0-72-generic Architecture: x86-64

VSCodium:

Version: 1.78.2 Release: 23132 Commit: e06ea6147733c975d26c3d3552462681e05cb147 Date: 2023-05-12T00:42:22.773Z Electron: 22.3.5 Chromium: 108.0.5359.215 Node.js: 16.17.1 V8: 10.8.168.25-electron.0 OS: Linux x64 5.15.0-72-generic Sandboxed: No

[SkullHex2]

Not fixed yet.

Version:	1.79.2
Release:	23166
Commit:	19c0f5cefaeb2637b45a9c7a356151fcfdcda1e9
Date:	2023-06-15T18:19:23.116Z
Browser:	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) VSCodium/1.79.2 Chrome/108.0.5359.215 Electron/22.3.10 Safari/537.36

[BloodyRain2k]

I just finally switched from Windows to Debian and now I got this issue on my hands...

Version: 1.84.2
Release: 23317
Commit: c8ce3ba4bc6b30b3b10edc61481cb85b1d2396bc
Date: 2023-11-13T18:24:10.824Z
Electron: 25.9.2
ElectronBuildId: undefined
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.1.0-13-amd64

[daiyam]

We can't do anything since it's a bug in Electron so it's up to Microsoft to fix it...

[BloodyRain2k]

We can't do anything since it's a bug in Electron so it's up to Microsoft to fix it...

Yeah, that's not gonna get fixed at all then. Why should they fix an issue that only exists on a competing OS?

Sour ranting aside, after messing around with whatever options I can find in the OS and what not, I wanna throw an idea into the room. But since I've literally just switched this week, forgive me if I spout nonsense for a lack of understanding how the whole stuff works:

I noticed that it's possible to set various actions for windows when clicking the titlebar, one of them being "lower" which drops that window behind others. Since we apparently can't get the handle for the "Save As" dialog, would it be possible to "drop" the main window instead until the dialog is 'done' doing it's dialog things?

It'd be a messy work around, but it could potentially be a workaround for those that can't use KDE's "Window Rules" stuff. Although I'm really contemplating to switch to KDE now just for that.

[Crystal-RainSlide]

@BloodyRain2k I found this Gnome extension called Grand Theft Focus from a reply in the Electron issue (https://github.com/electron/electron/issues/32857#issuecomment-1697579690), which seems to do the thing:

• https://github.com/zalckos/GrandTheftFocus
• https://extensions.gnome.org/extension/5410/grand-theft-focus/

---

There are some 3rd party Window management tools that directly work on X or Wayland may help, if they can be executed somehow just after the file dialog goes behind main window:

• https://old.reddit.com/r/gnome/comments/u929n6/customizable_windows_rules/i5q3v7r/
  • wmctrl -F -a '<window title of the file dialog>'
• For Wayland: https://git.sr.ht/~brocellous/wlrctl
  • wlrctl window focus app_id:codium title:<window title of the file dialog>

Also, for Compiz, the updated link for its Window Rules feature (previously mentioned by stotes, sadly that link will not redirect to current one): https://www.compiz-fusion.org/wiki_subdomain/windowmatching.html#Window_Rules

[BloodyRain2k]

• https://github.com/zalckos/GrandTheftFocus
• https://extensions.gnome.org/extension/5410/grand-theft-focus/

Also, for Compiz, the updated link for its Window Rules feature previously mentioned by stotes: https://www.compiz-fusion.org/wiki_subdomain/windowmatching.html#Window_Rules

Thanks, but I've found those two too after some hours of searching. Problem is that I'm using Cinnamon currently and have literally no idea how to install gnome extensions. When I tried to install the "shell" part that seems to be needed for that, the packet manager wanted to replace Cinnamon with gnome instead...

As for Compiz, tried that too... It just removes every single window decorator and my taskbar and makes the UI basically unusable. And that was just from starting it without touching the config... I'll try AutoKey instead later, which might be the best option for me as I'm already used to AutoHotKey.

But I've started wondering about something else: the first dialog doesn't seem to have any issue appearing on top of the main window. I might have missed it so sorry if this was already covered, but would it be worth a shot to just create a brand new instance of the dialog each time? I would assume that by default, it just gets hidden afterwards and prepared and reused the next time it's needed, which then triggers gnomes annoying behavior? Or is that handled internally by Electron and VSC has no say in that?

[kritonios01]

Still a bug on VS Codium v1.85.1. I am using Arch (EndeavourOS) on KDE

[3xploiton3]

still a bug on Arch Cinnamon

Version: 1.85.1
Release: 23348
Commit: 08e6c15293922dd53a864bb041be381322fee401
Date: 2023-12-14T20:36:42.296Z
Electron: 25.9.7
ElectronBuildId: undefined
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.6.9-arch1-1

[driscollw]

I guess I'll add to the chain. I'm seeing this as well.

Arch (EndeavourOS) on KDE Version: 1.85.2 Release: 24019 Commit: c8a36a69377856369f139f39ee56dd3838130fbf Date: 2024-01-19T18:30:44.948Z Electron: 25.9.7 ElectronBuildId: undefined Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Linux x64 6.7.3-arch1-2

[Jacalz]

I am also seeing this on Fedora Workstation 39 (Gnome desktop). Quite annoying. VSCodium from Flathub seems to be using the file pickers from the XDG Desktop Portal and those do not seem to be having the issue (they also look a lot nicer). Can the regular VSCodium binaries not be updated to also use the desktop portals for opening files (instead of the old electron provided GTK+3 file pickers)?

I have attached images of the old vs new file pickers below for reference. I hope this helps to solve the issue.

[Jacalz]

Why close this? It is obviously an issue for a lot of people

[playgithub]

It is an upstream bug and keep unsolved for years, there are links to the upstream issues in this issue. It's better to track the upstream issues for this problem.