Describe the bug
Launching the OpenContext_0.2.7_amd64.AppImage opens a window with the correct title bar, but the content area stays gray/blank indefinitely. No crash, no error dialog — the process just sits there.
Environment
- OpenContext version: 0.2.7 (AppImage, amd64)
- Kernel: 7.0.0-14-generic
- Mesa: 26.0.3-1ubuntu1
- GPU: Intel CometLake-U GT2 (UHD Graphics)
- Session type: Wayland (
XDG_SESSION_TYPE=wayland)
- System
libwebkit2gtk-4.1-0: 2.52.0
Diagnosis
Verbose logs show a repeating fatal line from the renderer:
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...
Traced this string to the AppImage's bundled usr/lib/libwebkit2gtk-4.1.so.0 (confirmed via --appimage-extract + grep). The app is Tauri-based, not Electron, so it ships its own WebKitGTK + GStreamer build rather than using the system libraries.
Confirmed the system graphics stack itself is healthy (Chrome 149 renders fine on this same machine), so the issue is specific to the bundled WebKitGTK failing EGL init against this newer Mesa version.
What I tried (no effect)
WEBKIT_DISABLE_DMABUF_RENDERER=1- Forcing the system's WebKitGTK 2.52.0 in place of the bundled one via
LD_LIBRARY_PATH — this surfaces ABI mismatches against the bundled GStreamer/GLib (undefined symbol: gst_pad_probe_info_set_buffer, then g_once_init_leave_pointer), confirming the bundle's WebKitGTK/GStreamer/GLib versions are tightly coupled and can't be mixed with system libs.
Suggested fix
Bump the bundled WebKitGTK (and matching GStreamer) to a version with Mesa 26.x-compatible EGL init, or fall back to non-accelerated compositing automatically when EGL init fails instead of leaving a blank window.
Describe the bug
Launching the
OpenContext_0.2.7_amd64.AppImageopens a window with the correct title bar, but the content area stays gray/blank indefinitely. No crash, no error dialog — the process just sits there.Environment
XDG_SESSION_TYPE=wayland)libwebkit2gtk-4.1-0: 2.52.0Diagnosis
Verbose logs show a repeating fatal line from the renderer:
Traced this string to the AppImage's bundled
usr/lib/libwebkit2gtk-4.1.so.0(confirmed via--appimage-extract+grep). The app is Tauri-based, not Electron, so it ships its own WebKitGTK + GStreamer build rather than using the system libraries.Confirmed the system graphics stack itself is healthy (Chrome 149 renders fine on this same machine), so the issue is specific to the bundled WebKitGTK failing EGL init against this newer Mesa version.
What I tried (no effect)
WEBKIT_DISABLE_DMABUF_RENDERER=1LD_LIBRARY_PATH— this surfaces ABI mismatches against the bundled GStreamer/GLib (undefined symbol: gst_pad_probe_info_set_buffer, theng_once_init_leave_pointer), confirming the bundle's WebKitGTK/GStreamer/GLib versions are tightly coupled and can't be mixed with system libs.Suggested fix
Bump the bundled WebKitGTK (and matching GStreamer) to a version with Mesa 26.x-compatible EGL init, or fall back to non-accelerated compositing automatically when EGL init fails instead of leaving a blank window.