Repository navigation
Event ready-to-show not triggering/inconsistent trigger on wayland #48859
Description
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
38.6.0
What operating system(s) are you using?
Ubuntu
Operating System Version
Ubuntu 24.04
What arch are you using?
x64
Last Known Working Electron version
37.9.0
Does the issue also appear in Chromium / Google Chrome?
I don't know how to test
Expected Behavior
The event ready-to-show should trigger when the window is created with show: false and the window is ready to be shown no matter if running on x11 or wayland.
Actual Behavior
Starting from Electron 38, the event ready-to-show is either not triggering or is inconsistent on wayland.
This worked fine on Electon 37 with wayland so I imagine it has something to do with Chromium ozone changes.
Testcase Gist URL
Additional Information
If you run this gist on 37 you will see the window open, but all versions more recent will not show the window on wayland.
Reacted by Jaume Zaragoza, Grzegorz Zdunek, Ondrej Medek, Grigorii K. Shartsev, Ben Bucksch, Roman Nabukhotnyi, Pachakutiq, Maja Cieślak and Eleno Trindade Gomes Jr
Activity
Sytten commentedon Nov 9, 2025
If you cannot get to "fail" with the gist, you can try replacing the
index.htmlload by a.loadURL("https://google.com").nikwen commentedon Nov 10, 2025
Thanks for opening this issue and for the repro! CC @mitchchn.
mitchchn commentedon Nov 11, 2025
@nikwen I have also experienced windows not firing
ready-to-showand not appearing when the GPU is disabled, but only sporadically. I believe these are related to GPU timing/synchronization issues in Chromium and am filing the ones that I can repro there.@Sytten do you use an NVIDIA GPU by any chance?
Sytten commentedon Nov 12, 2025
This was tested in VMware fusion on an M3 MBP Pro with 3d acceleration enabled (so no?). We had a lot of users report the bug to us on many setups and I cant imagine all of them use nvidia. But I saw GPU related error logs so that might be related.
mitchchn commentedon Nov 12, 2025
@Sytten yes, I’ve also reproed the lack of “ready-to-show” and similar issues in hardware accelerated VMs on a Mac (Parallels) as well as on bare metal with Nvidia GPUs. (But not with AMD or Intel which is why I was curious.)
I believe these bugs are likely related to upstream GPU sync issues in Chromium. The issues did seem to be more common in Electron 38 (and chromium 140) than more recent versions of each, and on 40.x betas I cannot repro them in my VM anymore. Not saying the problem is solved but do you see any difference with the newest pre-release versions?
13 remaining items
ravicious commentedon May 5, 2026
bump
zach20scott commentedon Jul 23, 2026
bump
qeelei commentedon Aug 29, 2026
Still reproducible on Electron 42.0.1. Adding a data point since this seems GPU-dependent:
xlsclients: no entry for the app)Repro:
BrowserWindowcreated withshow: false+once('ready-to-show', () => win.show()).ready-to-shownever fires on this setup — the main process stays alive, the renderer finishes loading, anddid-finish-loadfires (verified via logging), but the window stays hidden forever.User-visible symptom: clicking the menu item appears to do nothing on the first click; the second click works, because the window was already created and the code path falls back to calling
window.show()directly.Workaround that fixed it for us: reveal the window on
did-finish-loadif!win.isVisible()(Linux-only, first-wins), same approach as FreeTubeApp/FreeTube#8294. Happy to test any patch or pre-release build that addresses this.jnsgruk commentedon Sep 1, 2026
This also just showed up in Signal Desktop on Linux - see snapcrafters/signal-desktop#474
fix: enable GPU acceleration by default
ell1e commentedon Sep 1, 2026
No messenger needs GPUs, and most messengers use electron now. I always disable GPU access through flatpak since it's way more of a security risk than of any use, even on a phone (since even those devices are fast enough). It also seems like some people hit this even with GPUs.
Anyway, I wanted to point this out since I was hoping it will motivate more interest in a fix for the non-GPU case.
Show the editor window on Wayland even without ready-to-show
Show the editor window on Wayland even without ready-to-show
Show the main window on Linux Wayland, where ready-to-show never fires (
Release Frink on Linux (x64 and arm64 AppImage and .deb) (#328)
Bitsonwheels commentedon Oct 22, 2026
Adding a data point from a first-run hang we reproduced on RHEL 10.2 (GNOME Wayland session, kernel 6.12, AppImage app — Electron 44.4.5). The GPU is fully software-rendered in this setup (gpu_compositing: disabled_software, 2d_canvas: disabled_software), so this is not a hardware acceleration path.
Symptom: on 4/4 fresh first starts, a first-run picker window (created with show:false and revealed only on ready-to-show) never got mapped — the window never appears, the app waits indefinitely on a promise resolved only by that window's UI, and nothing ever listens on the app's port. The Electron processes and children stay alive the whole time. Setting the mode directly in the app's config (bypassing the picker) boots normally on the same session, which isolates the failure to the window reveal rather than the boot logic.
Show the main window on did-finish-load on Linux (#3351)
Start on XWayland when software rendering is on under Wayland (#8765)