Summary
On an Arch-based host (EndeavourOS) running Mesa 26.x + libglvnd, the official linux-x86_64 AppImage (v1.0.1) opens but stays blank/white. WebKit's WebProcess aborts during EGL initialization and never comes back:
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...
The GTK shell window survives, so the user-visible symptom is a permanent blank window rather than a crash.
This appears to be the same AppImage packaging issue documented for another Tauri + WebKitGTK app here: sftwrdotdev/Markpad#498
Environment
- Host: EndeavourOS (Arch-based), x86_64, VM without usable GPU (VMware 3D acceleration off; software rendering via llvmpipe)
- Mesa 1:26.2.2, libglvnd 1.7.0, system webkit2gtk-4.1 2.52.6
- Session: X11 via xrdp/Xvnc (
DISPLAY=:10)
- OpenBitFun v1.0.1 AppImage (
OpenBitFun_1.0.1_linux-x86_64.AppImage)
Symptoms / observed behavior
- stderr right after the banner
=== OpenBitFun Desktop Starting ===:
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting... (pure-Mesa environment)- On a system that additionally carries leftover NVIDIA EGL vendor files (
/usr/share/glvnd/egl_vendor.d/10_nvidia.json, libnvidia-*.so), the first failure instead surfaces as Could not create surfaceless EGL display: EGL_BAD_ALLOC. Aborting... — same root area, different vendor path.
- No
WebKitWebProcess is ever alive (it dies at startup); only WebKitNetworkProcess survives, so the page never renders.
webview.log stays 0 bytes; app.log shows Startup page did not finish loading before the window reveal watchdog.- Reproduced both from the FUSE-mounted AppImage and via
--appimage-extract-and-run. A strace of the dying WebProcess shows it loading /usr/lib/libEGL.so.1 (glvnd), then aborting right after vendor probing — before any DRI driver is reached.
Root cause analysis
The AppImage bundles usr/lib/libwayland-client.so.0 (built against the ubuntu-24.04 runner). Because LD_LIBRARY_PATH puts the AppImage directories first, that older copy shadows the host's libwayland-client for every process in the AppImage tree, including WebKit's WebProcess. The host libEGL (libglvnd) links libwayland-client, and with the mismatched older copy in place, eglGetPlatformDisplay is rejected at the EGL dispatch entry with EGL_BAD_PARAMETER before any DRI driver is even loaded (Mesa verbose logging prints nothing useful, consistent with a rejection at dispatch entry).
This matches exactly the single-library isolation result reported in Markpad #498 (same stack: Tauri + WebKitGTK 2.52.x AppImage built on ubuntu-24.04, tested on Arch/Mesa 26): removing only libwayland-client.so.0 from the AppDir is necessary and sufficient — the full UI then renders.
Verification performed (on this host)
- Extracted the published v1.0.1 AppImage to a directory (
--appimage-extract).
- Deleted only
squashfs-root/usr/lib/libwayland-client.so.0.
- Ran the extracted
AppRun with WEBKIT_DISABLE_DMABUF_RENDERER=1 on an X11 session.
- Result:
WebKitWebProcess stays alive, no EGL abort on stderr, webview.log fills up — the frontend completes full startup (Tauri API initialized, Monaco Editor initialized, I18n / config / language registries ready) and no watchdog warning is emitted. UI renders normally.
Note: env workarounds alone (WEBKIT_DISABLE_DMABUF_RENDERER=1, WEBKIT_DISABLE_COMPOSITING_MODE=1, LIBGL_ALWAYS_SOFTWARE=1) do not fix the shipping AppImage — consistent with Markpad #498's findings.
Suggested fix
Exclude host-coupled graphics libraries from the AppImage at build time (linuxdeploy excludelist, per AppImageCommunity/pkg2appimage guidance) — at minimum libwayland-client.so.0, ideally the full set: libwayland-*, plus libEGL/libGL/libgbm/libdrm/libxcb* if present.
Caveat for maintainers: a repacked AppImage must be re-signed and latest.json regenerated, or the auto-updater breaks (same note as in Markpad #498).
Repro caveat
The bug is host-version dependent: it only manifests when the host's Mesa/libwayland are newer than the build runner's. Builds and tests on the ubuntu-24.04 runner (or on hosts matching it) will not catch this; a CI smoke test on a recent Arch/Mesa image would have caught both this and any future recurrence of the same class of packaging problem.
Summary
On an Arch-based host (EndeavourOS) running Mesa 26.x + libglvnd, the official
linux-x86_64AppImage (v1.0.1) opens but stays blank/white. WebKit's WebProcess aborts during EGL initialization and never comes back:The GTK shell window survives, so the user-visible symptom is a permanent blank window rather than a crash.
This appears to be the same AppImage packaging issue documented for another Tauri + WebKitGTK app here: sftwrdotdev/Markpad#498
Environment
DISPLAY=:10)OpenBitFun_1.0.1_linux-x86_64.AppImage)Symptoms / observed behavior
=== OpenBitFun Desktop Starting ===:Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...(pure-Mesa environment)/usr/share/glvnd/egl_vendor.d/10_nvidia.json,libnvidia-*.so), the first failure instead surfaces asCould not create surfaceless EGL display: EGL_BAD_ALLOC. Aborting...— same root area, different vendor path.WebKitWebProcessis ever alive (it dies at startup); onlyWebKitNetworkProcesssurvives, so the page never renders.webview.logstays 0 bytes;app.logshowsStartup page did not finish loading before the window reveal watchdog.--appimage-extract-and-run. A strace of the dying WebProcess shows it loading/usr/lib/libEGL.so.1(glvnd), then aborting right after vendor probing — before any DRI driver is reached.Root cause analysis
The AppImage bundles
usr/lib/libwayland-client.so.0(built against the ubuntu-24.04 runner). BecauseLD_LIBRARY_PATHputs the AppImage directories first, that older copy shadows the host's libwayland-client for every process in the AppImage tree, including WebKit's WebProcess. The hostlibEGL(libglvnd) linkslibwayland-client, and with the mismatched older copy in place,eglGetPlatformDisplayis rejected at the EGL dispatch entry withEGL_BAD_PARAMETERbefore any DRI driver is even loaded (Mesa verbose logging prints nothing useful, consistent with a rejection at dispatch entry).This matches exactly the single-library isolation result reported in Markpad #498 (same stack: Tauri + WebKitGTK 2.52.x AppImage built on ubuntu-24.04, tested on Arch/Mesa 26): removing only
libwayland-client.so.0from the AppDir is necessary and sufficient — the full UI then renders.Verification performed (on this host)
--appimage-extract).squashfs-root/usr/lib/libwayland-client.so.0.AppRunwithWEBKIT_DISABLE_DMABUF_RENDERER=1on an X11 session.WebKitWebProcessstays alive, no EGL abort on stderr,webview.logfills up — the frontend completes full startup (Tauri API initialized, Monaco Editor initialized, I18n / config / language registries ready) and no watchdog warning is emitted. UI renders normally.Note: env workarounds alone (
WEBKIT_DISABLE_DMABUF_RENDERER=1,WEBKIT_DISABLE_COMPOSITING_MODE=1,LIBGL_ALWAYS_SOFTWARE=1) do not fix the shipping AppImage — consistent with Markpad #498's findings.Suggested fix
Exclude host-coupled graphics libraries from the AppImage at build time (linuxdeploy excludelist, per AppImageCommunity/pkg2appimage guidance) — at minimum
libwayland-client.so.0, ideally the full set:libwayland-*, pluslibEGL/libGL/libgbm/libdrm/libxcb*if present.Caveat for maintainers: a repacked AppImage must be re-signed and
latest.jsonregenerated, or the auto-updater breaks (same note as in Markpad #498).Repro caveat
The bug is host-version dependent: it only manifests when the host's Mesa/libwayland are newer than the build runner's. Builds and tests on the ubuntu-24.04 runner (or on hosts matching it) will not catch this; a CI smoke test on a recent Arch/Mesa image would have caught both this and any future recurrence of the same class of packaging problem.