[Bug] Linux AppImage: bundled libwayland-client.so.0 breaks EGL on newer Mesa hosts - WebProcess aborts (EGL_BAD_PARAMETER), blank window #3226

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)

1. Extracted the published v1.0.1 AppImage to a directory (--appimage-extract).
2. Deleted only squashfs-root/usr/lib/libwayland-client.so.0.
3. Ran the extracted AppRun with WEBKIT_DISABLE_DMABUF_RENDERER=1 on an X11 session.
4. 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.