You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Linux: forced WEBKIT_DISABLE_DMABUF_RENDERER=1 makes the main window transparent on WebKitGTK 2.54 (only repainted regions show) #2624
On Linux with WebKitGTK 2.54, Cap's main window is almost entirely invisible. The window exists (KWin reports it mapped, 330×395, not hidden/minimized), but only the regions that get repainted show up: a hovered button, a toggle being animated, etc. Everything else stays transparent, so you see the desktop through the window.
The cause is the unconditional override added for #1948:
With WebKitGTK 2.54, disabling the DMABUF renderer on a transparent window makes WebKit repaint only the damaged areas, and the rest of the surface is never painted. Other Tauri projects hit the same regression on 2.54 (e.g. rogeriojunior31/Vults#126, xnmp/tauri-explorer#1057).
Because the variable is overwritten with set_var, users can't opt out: running WEBKIT_DISABLE_DMABUF_RENDERER=0 Cap still yields WEBKIT_DISABLE_DMABUF_RENDERER=1 in the environment of Cap's WebKitWebProcess (checked via /proc/<pid>/environ).
Reproduction
Debian 13, KDE Plasma 6.3 Wayland, WebKitGTK 2.54.0.
Install Cap 0.6.0 (.deb) and launch it.
The main window is transparent except for elements being hovered or animated.
What I tried
All of these still show the bug, because the forced variable stays in effect:
GDK_BACKEND=x11 (XWayland)
WEBKIT_DISABLE_COMPOSITING_MODE=1
WEBKIT_SKIA_ENABLE_CPU_RENDERING=1
forcing Mesa EGL instead of NVIDIA (__EGL_VENDOR_LIBRARY_FILENAMES=.../50_mesa.json)
WEBKIT_FORCE_COMPOSITING_MODE=1
Workaround that fixes it: an LD_PRELOAD shim that turns setenv("WEBKIT_DISABLE_DMABUF_RENDERER", …) into a no-op. With the variable unset, the window renders fully and correctly on this machine.
Better still, don't apply the workaround by default on WebKitGTK ≥ 2.54 (or limit it to the configurations from #1948), since it now breaks rendering instead of fixing it.
#2628 should fix this: a value you set yourself is now respected, and Cap only forces the workaround below WebKitGTK 2.54. If you can build that branch, I'd love to know whether the main window paints on your Debian 13 / Plasma setup.
Activity
linear commentedon Oct 15, 2026
CAP-849
AatmanAJ commentedon Oct 15, 2026
#2628 should fix this: a value you set yourself is now respected, and Cap only forces the workaround below WebKitGTK 2.54. If you can build that branch, I'd love to know whether the main window paints on your Debian 13 / Plasma setup.