[Linux] Overlay keeps its last frame on screen after dictation even with host WebKitGTK 2.52 (KDE Plasma 6.7, XWayland)

[mkuhl]

Summary

With the host's WebKitGTK in use (not the bundled one), the overlay still stays on screen after every dictation, frozen on its last frame. docs/overlays.md ("How the Overlay Works", second paragraph) says preferring the host WebKitGTK resolves both this and the closing-animation smear. On this setup it resolves neither.

Related: #116 (overlay not disappearing, closed as fixed in 0.5.9) and #119 (closing animation smears, closed as fixed in 0.6.1). Both still reproduce here on 0.6.3 with host WebKitGTK 2.52.5.

Environment

• VoxCtrl 0.6.3 (build 927b660), VoxCtrl-linux-x86_64-vulkan.AppImage (sha256 efa282a8bc4b71f78863d3cf1f3c912062fe72bf4369b7aa1bc22a456d41d39f, matches the release asset)
• Host: Fedora Atomic 44 (Aurora DX), KDE Plasma / KWin 6.7.4, Wayland, Xwayland 24.1.13, kernel 7.1.8, AMD HawkPoint iGPU
• VoxCtrl runs inside a Fedora 44 distrobox that provides webkit2gtk4.1 2.52.5 (Mesa 26.2.2), because the atomic host has no webkit2gtk4.1. Display, session bus and compositor are the host's, so the attached system info shows the container OS.
• The host-first hook picks the box's WebKitGTK: the process maps /usr/lib64/libwebkit2gtk-4.1.so.0.21.9, its WebKit helpers run from /usr/libexec/webkit2gtk-4.1, and the fallback symlink directory is empty.
• Two monitors (4K primary, scaled laptop panel)

What happens

1. Dictate with the hotkey, target Focused Window (xdotool). The text arrives and the log shows "Delivered".
2. The overlay does not go away. It stays above all windows, frozen on its last frame (tried Voice Card and Mono Bars; both stay showing PROCESSING).
3. With default WebKit settings the closing animation also smears: copies of the card at many widths pile up and stay.

Evidence

• The window "VoxCtrl Overlay" is depth 32, WM_STATE Normal, _NET_WM_STATE_ABOVE, and stays mapped while idle (as documented).
• I read the window contents with XGetImage (ImageMagick "import -window"), which returns the client's buffer, not the compositor's output. The buffer itself holds the stale frame (with compositing on: the stacked frames of the closing animation). So the stale pixels come from the client side, not from KWin.
• A real resize repaints it: growing the window by 2 px through a KWin script, then shrinking it back in a second run, clears buffer and screen at once. Grow and restore in the same script run get merged and change nothing.

Ruled out

• Bundled WebKitGTK: not loaded (see above).
• Compositor: the client buffer itself is stale.
• WEBKIT_DISABLE_COMPOSITING_MODE=1 with WebKitGTK 2.52.5 removes the smear, but the last frame still stays.
• With the bundled WebKitGTK, WEBKIT_DISABLE_DMABUF_RENDERER=1, WEBKIT_SKIA_ENABLE_CPU_RENDERING=1 and LIBGL_ALWAYS_SOFTWARE=1 changed nothing. I did not repeat those with 2.52.5.

Workaround

Launch with WEBKIT_DISABLE_COMPOSITING_MODE=1 and pipe VoxCtrl's stdout through a small script. 1 s and 3 s after each "Delivered" or "Delivery failed" line, it resizes the overlay by 2 px and back through KWin's scripting D-Bus API. The overlay then clears 1–3 s after delivery. It does not cover dictations that end without a delivery.

Ask

Make the idle overlay reliably repaint to blank whichever WebKitGTK is in use. For example: unmap the window while idle, force a redraw or resize after the idle state is painted, or bring back destroy-when-idle on Linux/XWayland. Happy to test a build.

---

Filed directly on GitHub rather than through the in-app Bug Report page. Happy to attach a saved in-app report or the startup_errors.log if useful.

[JRufer]

Really appreciate the depth of root-causing here (the XGetImage buffer check ruling out the compositor was especially useful). A best-effort mitigation is in v0.6.4 (PR #137): since your own KWin-script workaround (a real resize forces the client's stale buffer to repaint) reliably clears it, I've reproduced the same fix inside the app itself — after each dictation ends, VoxCtrl now nudges the overlay window with a 2px resize-and-restore (via tauri's own set_size, not anything KDE-specific) at 1s and 3s after going idle.

I don't have your KDE/XWayland/host-WebKitGTK 2.52.5 setup to confirm this actually clears it the way your manual script did, so this is a genuine "please test" — could you try v0.6.4 once it's out and let me know whether the overlay still gets stuck after a dictation? If the built-in nudge doesn't work where your KWin script did, there may be a timing or scope difference worth comparing.

[mkuhl]

Tested on v0.6.5 (build 866035d). The built-in nudge clears the overlay. After each dictation the overlay now disappears on its own, with my KWin-script workaround removed entirely — so the 2px resize-and-restore via set_size does reach the client the same way an external resize did. Your version is also better than mine in one way: it fires on the idle transition rather than on a delivery, so it covers dictations that end without one (no speech, cancel), which my watcher never handled.

Setup: VoxCtrl 0.6.5 AppImage in a Fedora 44 distrobox providing webkit2gtk4.1 2.52.5 (maps /usr/lib64/libwebkit2gtk-4.1.so.0.21.9), on a Fedora Atomic host, KDE Plasma/KWin 6.7.4, Wayland, overlay on XWayland.

One thing left, much smaller than before: with accelerated compositing enabled the closing animation still smears (several copies of the card piling up), but the nudge wipes it about a second later, so it is now a brief visual glitch rather than something stuck on screen. WEBKIT_DISABLE_COMPOSITING_MODE=1 still avoids it completely, and I have kept that in my launcher — it costs nothing for a page this small. Happy to test anything further here, or to have this closed as good enough if you prefer; from my side it is no longer a real problem.

Thank you as well for the turnaround — three issues root-caused, fixed and released within hours of filing, with a fix that generalized my workaround rather than just taking it. VoxCtrl is a genuinely great piece of software, and the care in the docs (the AppRun hook comments were what pointed me at the bundled WebKitGTK in the first place) made the debugging far easier than it would otherwise have been.

[JRufer]

Thank you very much for the extra info and the feedback. I am really happy with this project and I want to make it the best I can. I will see if there is any way I can address the accelerated compositing issue when I can.
Please feel free to report anything else you find or make feature requests if you like. This is a bit of a balancing act, trying to offer users all the customization they can use without making the app a nightmare to use. :)