You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Wayland app quits with SIGTRAP when the compositor rejects a surface export #55141
Does the issue also appear in Chromium / Google Chrome?
I don't know how to test
Expected Behavior
The app stays open. One rejected Wayland surface export should not quit the process.
Actual Behavior
Granola, launched as /usr/lib/electron44/electron --ozone-platform-hint=auto /usr/lib/granola/app.asar, vanished after about 80 minutes. systemd-coredump recorded SIGTRAP for that process. The app started again on its own. No reliable steps to reproduce.
Testcase Gist URL
None. This was a one-off crash in a packaged app, not something I could reduce to an Electron Fiddle.
Additional Information
Wayland session under Hyprland 0.56.2. Chrome version string in the binary is 152.0.7977.167.
In-depth investigation
The faulting instruction is int3 followed by ud2. The main thread was in glib's main loop, in the Wayland event-source callback, in ui/events/platform/wayland/wayland_event_watcher.cc (WlDisplayDispatchPendingQueue). wl_display_dispatch_queue_pending had failed. rbx was 71 (EPROTO).
Crash-key memory held:
zxdg_exporter_v2#29: error 0: surface must be an xdg_toplevel
and compositor name Hyprland. Error 0 is invalid_surface on export_toplevel. The watcher then executes CHECK(err == EPIPE || err == ECONNRESET), so a protocol error traps instead of shutting down cleanly. Electron debug symbols were not available; those names come from strings in the function on the stack, the errno register, and the crash key.
Can you test if it also happens for Chromium? Chromium exports the surface when opening a file chooser too:
[03:18:57.657629] -> zxdg_exporter_v2#24.export_toplevel(new id zxdg_exported_v2#90, wl_surface#34)
[03:18:57.657815] zxdg_exported_v2#90.handle("ed041120-4b75-4f57-8155-6a45362c4bf2")
If it also crashes the Chromium, you will need to report this to Chromium team, as Electron reuses the Ozone from Chromium.
If you don't know why/how to make your compositor reject a surface export, can you provide a stack trace? More information is needed to make the investigation easier.
Hello @shawnyeager. Thanks for reporting this and helping to make Electron better!
Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.
Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.
Now adding the
blocked/need-reproNeeds a test case to reproduce the bug
label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.
Activity
YUCLing commentedon Oct 21, 2026
Can you test if it also happens for Chromium? Chromium exports the surface when opening a file chooser too:
If it also crashes the Chromium, you will need to report this to Chromium team, as Electron reuses the Ozone from Chromium.
If you don't know why/how to make your compositor reject a surface export, can you provide a stack trace? More information is needed to make the investigation easier.
electron-issue-triage commentedon Oct 21, 2026
Hello @shawnyeager. Thanks for reporting this and helping to make Electron better!
Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.
Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.
Now adding the blocked/need-reproNeeds a test case to reproduce the bug
label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.
shawnyeager commentedon Oct 22, 2026
Standalone case: https://gist.github.com/shawnyeager/075489575612c6d54abab381bca8e8ed
dialog.showMessageBoxwith aBrowserWindowthat hasshow: falsequits the process on Wayland. The same call after the window has been shown does not.Reproduced twice on Electron 44.9.3, Arch Linux, Hyprland 0.56.2,
--ozone-platform-hint=auto. stderr:libwayland: zxdg_exporter_v2#29: error 0: surface must be an xdg_toplevelThe process then dies with SIGTRAP. Open the gist in Electron Fiddle, or run
main.jswith the systemelectronbinary on Wayland.YUCLing commentedon Oct 23, 2026
@shawnyeager Thank you for your fiddle. I can produce this and I think this should be a Chromium side fix. Electron can only do the band-aid fix, so it cannot cover all cases, e.g.: https://gist.github.com/YUCLing/62834e17fb6a305dbd4d271ab811dc7e
I'll see if I can make a repro with Chromium.
Note: Some compositors will not check the export surface, e.g. KWin, so not all Wayland compositors can reproduce this.
YUCLing commentedon Oct 23, 2026
Upstream CL: https://chromium-review.googlesource.com/c/chromium/src/+/8640149
I've test the patch locally and it solves the crash, hope it can be upstreamed smoothly.
[ozone/wayland] Do not export toplevels that have no role
basil commentedon Nov 2, 2026
@YUCLing Any chance this could be backported to the Electron 45 line?
YUCLing commentedon Nov 2, 2026
@basil Yes, as long as someone cherry-picks it. I might do it later.
basil commentedon Nov 3, 2026
@YUCLing Verified fixed as of 45.2.2. Thank you very much!