[Bug]: showOpenDialog / showSaveDialog opens _behind_ the app after the second call onward

[Prinzhorn]

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

16.0.8, 17.0.0, 18.0.0-alpha.1

What operating system are you using?

Ubuntu

Operating System Version

Linux alex-desktop 5.13.0-28-generic #31~20.04.1-Ubuntu SMP Wed Jan 19 14:08:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

Opening a file save / open dialog opens the dialog on top of the app

Actual Behavior

The first time it works, every dialog after that opens behind the app

Testcase Gist URL

https://gist.github.com/0302a1125c460df377ff8733e7ddb154

Additional Information

Related

#27053
#24959

But this doesn't require any special arguments.

Steps:

1. Run Fiddle
2. Click "Open File"
3. Cancel
4. Click "Open File" again
5. Dialog is off-center and behind the app

Fiddle itself has the same issue when I click "Save As"

[codebytere]

@Prinzhorn it looks like this is a function of a new-ish Gnome focus-stealing prevention behavior; it happens when a notification pops at the top saying "app_name is ready". I'll try to see if there's some kind of way around it. In the meantime, here's a workaround you can probably use: https://ubuntuhandbook.org/index.php/2020/12/quick-tip-remove-window-is-ready-notification-focus-window-immediately/

[Prinzhorn]

Thanks for looking into this. FWIW window.open with nativeWindowOpen does not have this issue (which is an entirely different window system I assume and not related to the gtk file dialog). Also Chromium itself doesn't have this issue either (e.g. hitting ctrl+s). The dialog opened by #32165 does have the same issue. I'm using Ubuntu exclusively and have never noticed this issue with other apps I'm using. So there must be a way to consistently open the window in focus.

[codebytere]

@Prinzhorn you're right - it happened after #19159 because the transient window isn't being set properly anymore. I'm looking into it :)

[Jelmerro]

I'm also running into this issue, but in my case I do not get the Gnome notification at all, and the workaround doesn't work either, as I'm using the Cinnamon DE, which was forked from Gnome a long time ago. But the issue is exactly the same, second dialog opens behind the window, and in my case breaks mouse interaction with both the parent and the dialog. I have to alt-tab and kill the app to get back any mouse interaction. Is there any more info required to resolve this issue, if so, I'll happily provide it, as this is quite a big issue for one of my apps. Interestingly, dialog.showMessageBox and dialog.showMessageBoxSync both work flawlessly.

[matheustavaresdev]

Also having this issue on our project as detailed in rstudio/rstudio#11100 . The first open file dialog called by showOpenDialog or showSaveDialog opens as it should. After the second, we get a System Notification and the dialog opens up behind the main window. This was identified as of now on Fedora 35, Ubuntu 20 and Ubuntu 22. This happens regardless we pass a window or not to those functions when opening a dialog.

[iggith]

Same here: a dialog preceded by notification opens behind the main window. The simplest case -- just a dialog.showOpenDialog call in a template application.

Electron Fiddle on the same machine: the file dialog works as expected no matter how many times used (no notifications as well), however About dialog triggers notification and opens behind the main window.

Ubuntu 20.04.4 LTS, GNOME 3.36.8
Node.js 16.13.2, Chromium 100.0.4896.143, Electron 18.2.1
Electron Fiddle 0.28.1

[origin-yaropolk]

Got this issue too

[quanzhuo]

After some test, I found that this issue didn't exist on electron 13.6.9 but appears in 14.0.1. Hope this information helps. @codebytere

[darac-10]

I use fedora 35, gnome 41, architecture x64, electron 19.x.y. and I have the same problem.
After several tests and attempts of old versions, I found that on version 17.4.7 everything is correct, and on version 18.x.y and higher the mentioned problem occurs.
The same problem is on both the X11 and the Wayland desktop environment.

the electron I use is not customized, but pre-built.
It is installed with npm install electron .

Hope this information helps.

[darac-10]

To be more precise. Maybe I missed it.

The problem always occurs after the second or more calls of the showOpenDialog method.

In version 17.4.7, the showOpenDialog dialog opens in front of the application but is out of focus and the notification tile is not displayed. After selecting the file, the dialog is in focus.

The user impression is that everything is fine, but still not. So version 17.4.7 is also affected by the problem

On version 18.3.3 and higher, in addition to the mentioned problem, the following occurs:
I run the program from the terminal with npm start
after that a few dozen lines with a message appear
ERROR: gbm_wrapper.cc (275) Failed to export buffer to dma_buf: No such file or directory (2)
In version 19.0.4 the message is similar:
ERROR: gbm_wrapper.cc (292) Failed to export buffer to dma_buf: No such file or directory (2)

I don't know if this has anything to do with the mentioned problem because it doesn't appear on version 17.4.7.

Greeting.

[codebytere]

@darac-10 as mentioned above, we already know precisely why this is occurring. It's simply that we don't know how to address the problem.

#32857 (comment)

[tristan957]

@codebytere, I have looked at this too (original author of the aforementioned PR), and I haven't found a way to fix it. I have previously advocated for reverting the PR since there is no easy solution that I can see to fix the problems.

[AlexandreBonneau]

I can't reproduce this with KDE, and they've had focus stealing prevention since 3.x. Maybe this is a GNOME/GTK bug instead of an Electron one?

I have been experiencing this (every time) on KDE for some time (a year?). Kubuntu 23.04, KDE backports.

This bug exists in KDE and is 100% reproducible since the beginning of times (I can remember being hit with it using Draw.io in 2018, so it's been going on at least 5 years now).
For info this is happening in Linux Debian using X11 (haven't tried wayland).

[tristan957]

I can remember being hit with it using Draw.io in 2018, so it's been going on at least 5 years now

As the author of the bug, this is incorrect. The bug was introduced in 2021.

[AlexandreBonneau]

My memory could fail me, but I'm pretty sure I experienced this bug from the get go, and I started using draw.io in 2018.
Or perhaps I first used draw.io within confluence for a few years before using the desktop version, and then got hit with that bug..

[espeluznante]

The first time it works fine, but when called a second time, the dialog box appears behind the main window.

[brtdylan]

I see this issue as well on ubuntu 22.04 when calling dialog.showOpenDialog with a parent window set. The first call seems to work, then the subsequent calls all open the dialog behind the app with the system notification triggered, etc

I noticed that when downloading a file via electron's webcontents::downloadURL API, and not manually setting a save path on the DownloadItem, a save dialog is opened. This dialog seems to work correctly, opening on top of the app and in focus. I looked into the electron source to see if I could identify what's different here, but I was quickly out of my depth. It looks like they end up using the same FileChooserDialog code path. However, I wanted to share this in case it's insightful in fixing the issue:

This seems to be where downloadURL eventually opens a properly functioning (save) dialog:

electron/shell/browser/electron_download_manager_delegate.cc

Line 272 in 62331f5

file_dialog::ShowSaveDialog(settings, std::move(dialog_promise));

and this is where I believe dialog.showOpenDialog leads to:

electron/shell/browser/api/electron_api_dialog.cc

Line 60 in 62331f5

v8::Local<v8::Promise> ShowOpenDialog(

I see in the earlier comments that there is a missing parent window param when creating the gtk dialog object. What I don't understand is why it works the first time 😅

[AlexandreBonneau]

On Debian testing (trixie) with Kde, the dialog is opened behind the parent window for the very first call when trying to 'Save as...' (tested with Draw.io desktop 24.0.4 which uses electron 28.1.0).

[morfyum]

I found similar issue in Gnome notification.
Supposedly come some improvement for gnome 46.
Gnome issue can related to this?

On Gnome with Firefox or any application can be reproduce.

When download something from Firefox, and click to "Open in folder" button, Firefox open Nautilus application.
When you dont close Nautilus, and navigate back to Firefox, and click again into "Open if folder" button, Gnome-shell just send a notification about opening. When I click to notification, Nautilus select this file, but stay in background.

Same issue on Fractal 6 client. When application in background, gnome send notification every message, but nitifications has no function. Won't open, won't move into top layer the application.

[starball5]

Is this related in any way to flatpak/xdg-desktop-portal-gtk#137?

[xing403]

关于这个问题(Linux Ubuntu 调用系统dialog 首次出现在应用顶层，之后调用 显示 已就绪 并且 dialog 一直在应用下方)，有什么可以解决的方法吗

[Jamtastic808]

Hi, any sign of a fix for this please?

[ReillyBrogan]

Hi, any sign of a fix for this please?

Do you see any Electron PRs linked to this issue? No? Then no there is no sign of a fix. Please avoid commenting if you have nothing to add to the issue.