Description of the issue
Brave running a web app window crashes shortly after this Omarchy/Hyprland laptop resumes from suspend. systemd-coredump recorded two SIGTRAP crashes with closely matching main-thread stack shapes:
| Date (America/Mexico_City) | Resume completed | Brave crashed | Brave version | App scale flag |
|---|---|---|---|---|
| 2026-09-24 | 13:07:41 | 13:08:11 | 1.95.104 | --force-device-scale-factor=1.0 |
| 2026-09-29 | 09:36:02 | 09:36:21 | 1.96.59 (Chromium 154) | --force-device-scale-factor=0.5 |
The window uses native Wayland (--ozone-platform=wayland) and a separate Brave user-data directory. The browser’s main process crashed, rather than a renderer. The web app URL and profile contents are omitted for privacy. The exact trigger during resume or window reconfiguration is not yet known.
How can this issue be reproduced?
- On a Hyprland Wayland session with an internal display and two external displays connected through a Thunderbolt dock, launch a Brave web app with a separate profile:
brave --ozone-platform=wayland --user-data-dir=<separate-profile> --app=<web-app-url>. - Leave the app running, suspend the laptop, then resume.
- The web app window may disappear shortly after resume. This occurred twice, approximately 19 and 30 seconds after resume. Reproduction is intermittent.
Actual result
The main Brave process exits with SIGTRAP. On September 29, the crashing instruction was int3 at brave+0x7ecd9c5 (saved RIP: brave+0x7ecd9c6). Disassembly shows branches to this trap if a rectangle width or height is zero. The rectangle in this core was (x=0, y=0, width=0, height=0). This is consistent with Brave reaching its Wayland window geometry path with an empty rectangle. Chromium’s WaylandToplevelWindow::SetWindowGeometry source says empty geometry must not be requested: https://chromium.googlesource.com/chromium/src/+/9c30fb37950c6a0a7ab2875f38ca3953e27963ae/ui/ozone/platform/wayland/host/wayland_toplevel_window.cc#642 . The Brave binary is stripped, so I cannot prove the exact C++ function or which event supplied the zero rectangle.
September 29 main-thread stack (ELF build ID 9087f15b197497f6870016d094709af79c1d7f31):
#0 brave+0x7ecd9c6 (SIGTRAP)
#1 brave+0x7eb292e
#2 brave+0x7eb8a19
#3 brave+0x7eb87f1
#4 brave+0x7eb24d8
#5 brave+0x7e990b5
#6 brave+0x7e9b9c8
#7 brave+0x7631d05
#8 brave+0x7631259
...
#16 g_main_context_iteration
The September 24 stack has the same shape, starting at brave+0x7f50206 and reaching g_main_context_iteration at frame 16. Offsets differ because Brave versions differ. There was no OOM kill; available memory remained. The journal shows the external Thunderbolt dock reconnecting after the September 29 resume.
Expected result
The web app window remains open and usable after suspend/resume. A transient empty window size should not terminate the browser process.
Brave version (About Brave)
Brave stable 1.96.59, Chromium 154, Arch package brave-bin 1:1.96.59-1. The earlier crash occurred on Brave stable 1.95.104.
Additional information
Omarchy 4.0.4 (Arch Linux), kernel 7.2.5-3-omarchy, Hyprland 0.56.2, native Wayland session. Intel Iris Xe and NVIDIA GeForce RTX 4070 Mobile, NVIDIA userspace driver 610.57.04, Mesa 26.2.2. Internal 2560x1600 display at scale 2; two external 1920x1080 displays at scale 1.6 through a Thunderbolt dock. The app launch also loads two Omarchy Chromium extensions and a local theme content script, and uses --force-renderer-accessibility; these have not been isolated as causes.
This has not yet been reproduced with extensions disabled, a fresh profile, or current standalone Chromium/Chrome. The core dump is not attached because it may contain private browser data. Sanitized debugger output can be provided on request.
