The exact log line in the issue (Could not create default EGL display: EGL_BAD_PARAMETER. Aborting.) is WebKitGTK's own DMA-BUF renderer — its default accelerated-compositing path since 2.42 — failing on the reporter's Mesa/driver/compositor combination under Wayland. It's printed directly to stderr by WebKitGTK's C code before Triple-C's own logging gets a chance to say anything, and it's an abort, not a soft failure.
Set WEBKIT_DISABLE_DMABUF_RENDERER=1 unconditionally on Linux in main(), before the Tauri builder runs (which is where GTK/WebKitGTK actually read it). There's no reliable way to detect just the affected combination ahead of time — this exact failure has also been reported under XWayland, not only pure-Wayland sessions — and WebKitGTK's fallback compositing path costs some rendering performance the app's UI doesn't need. A user who has already set the variable themselves (including to 0, to force the DMA-BUF path back on) is left alone.
Not addressed by this PR — the issue bundles three separate things and this only fixes the one that's an outright crash:
Links not opening on the host: the opener:allow-open-url capability and its http://*/https://* scope both look correct from a static read, so this is more likely an environment issue (missing xdg-open/no default browser association on a minimal install) than a code bug. Needs a diagnostic from the reporter before attempting a fix.
A native Arch/CachyOS package: a packaging/distribution feature request, separate scope from a bug fix.
Contributes to #34 (does not close it — the other two items remain open).
Test plan
cargo check / cargo clippy — clean, no new warnings
cargo test — 504 passed (unaffected; this file has no existing test harness)
Cannot verify the actual runtime fix without a real Wayland session on the affected hardware — this PR's own CI build (Linux/macOS/Windows via build-app-preview.yml) is the compilation-level check; the reporter would need to confirm the crash is actually gone on their CachyOS machine
## Summary
- The exact log line in the issue (`Could not create default EGL display: EGL_BAD_PARAMETER. Aborting.`) is WebKitGTK's own DMA-BUF renderer — its default accelerated-compositing path since 2.42 — failing on the reporter's Mesa/driver/compositor combination under Wayland. It's printed directly to stderr by WebKitGTK's C code before Triple-C's own logging gets a chance to say anything, and it's an abort, not a soft failure.
- Set `WEBKIT_DISABLE_DMABUF_RENDERER=1` unconditionally on Linux in `main()`, before the Tauri builder runs (which is where GTK/WebKitGTK actually read it). There's no reliable way to detect just the affected combination ahead of time — this exact failure has also been reported under XWayland, not only pure-Wayland sessions — and WebKitGTK's fallback compositing path costs some rendering performance the app's UI doesn't need. A user who has already set the variable themselves (including to `0`, to force the DMA-BUF path back on) is left alone.
**Not addressed by this PR** — the issue bundles three separate things and this only fixes the one that's an outright crash:
- Links not opening on the host: the `opener:allow-open-url` capability and its `http://*`/`https://*` scope both look correct from a static read, so this is more likely an environment issue (missing `xdg-open`/no default browser association on a minimal install) than a code bug. Needs a diagnostic from the reporter before attempting a fix.
- A native Arch/CachyOS package: a packaging/distribution feature request, separate scope from a bug fix.
Contributes to #34 (does not close it — the other two items remain open).
## Test plan
- [x] `cargo check` / `cargo clippy` — clean, no new warnings
- [x] `cargo test` — 504 passed (unaffected; this file has no existing test harness)
- [ ] Cannot verify the actual runtime fix without a real Wayland session on the affected hardware — this PR's own CI build (Linux/macOS/Windows via `build-app-preview.yml`) is the compilation-level check; the reporter would need to confirm the crash is actually gone on their CachyOS machine
Reported on CachyOS/Arch with Wayland: the app aborts immediately with
"Could not create default EGL display: EGL_BAD_PARAMETER. Aborting."
printed straight to stderr by WebKitGTK's own C code, before Triple-C's
own logging even gets a chance to say anything useful about it.
This is WebKitGTK's DMA-BUF renderer (its default accelerated-compositing
path since 2.42) failing on some Mesa/driver/compositor combinations. Set
WEBKIT_DISABLE_DMABUF_RENDERER=1 unconditionally on Linux before the Tauri
builder runs, which is where GTK/WebKitGTK actually read it — there's no
reliable way to detect the affected combination ahead of time (reports of
this exact failure exist under XWayland too, not just pure Wayland
sessions), and WebKitGTK's fallback compositing path costs some rendering
performance this app's UI doesn't need. Left alone if a user has already
set the variable themselves.
Does not address the other two things filed under the same issue (links
not opening on the host, and a request for a native Arch/CachyOS package)
— those need more information / are a separate scope, respectively.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
Review found: "nothing this app's UI depends on" is backwards — the
terminal's @xterm/addon-webgl renderer is exactly the GPU compositing path
this setting disables, it just degrades gracefully (the addon's own
construction already handles WebGL being unavailable) rather than
crashing. And the "not simply Wayland vs X11" justification for going
unconditional doesn't hold up: WAYLAND_DISPLAY is exported into an
XWayland client's environment too, so gating on it would have caught that
case as well — the real reason to go unconditional is that there's no
reliable heuristic for the thing that actually matters (which
Mesa/driver/compositor combination is affected), not that the naive gate
misses XWayland specifically.
Also noted, not changed: the env var leaks to whatever the app spawns
afterwards (a cold-launched default browser via xdg-open), and the "=0
re-enables it" parenthetical isn't verified against WebKitGTK's own
source, so softened to say what's actually guaranteed (an already-set
value is left alone) rather than assume presence-vs-boolean parsing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting.) is WebKitGTK's own DMA-BUF renderer — its default accelerated-compositing path since 2.42 — failing on the reporter's Mesa/driver/compositor combination under Wayland. It's printed directly to stderr by WebKitGTK's C code before Triple-C's own logging gets a chance to say anything, and it's an abort, not a soft failure.WEBKIT_DISABLE_DMABUF_RENDERER=1unconditionally on Linux inmain(), before the Tauri builder runs (which is where GTK/WebKitGTK actually read it). There's no reliable way to detect just the affected combination ahead of time — this exact failure has also been reported under XWayland, not only pure-Wayland sessions — and WebKitGTK's fallback compositing path costs some rendering performance the app's UI doesn't need. A user who has already set the variable themselves (including to0, to force the DMA-BUF path back on) is left alone.Not addressed by this PR — the issue bundles three separate things and this only fixes the one that's an outright crash:
opener:allow-open-urlcapability and itshttp://*/https://*scope both look correct from a static read, so this is more likely an environment issue (missingxdg-open/no default browser association on a minimal install) than a code bug. Needs a diagnostic from the reporter before attempting a fix.Contributes to #34 (does not close it — the other two items remain open).
Test plan
cargo check/cargo clippy— clean, no new warningscargo test— 504 passed (unaffected; this file has no existing test harness)build-app-preview.yml) is the compilation-level check; the reporter would need to confirm the crash is actually gone on their CachyOS machine