Linux Desktop App (WebKitGTK/Tauri): UI does not repaint automatically, only on window focus change or resize

Describe the bug

The GitHub Copilot Desktop App (Linux AppImage, v1.0.84-4) does not repaint/refresh its UI automatically. The window renders correctly once on launch, but stops updating after that — new content (chat responses, session state changes, etc.) is not shown until the window loses and regains focus (e.g. switching to another window and back), or its geometry changes (even a 1px resize forces exactly one repaint).

Environment

• OS: Linux Mint 22.3 (XFCE, xfwm4 window manager)
• App: GitHub Copilot Desktop (AppImage), version 1.0.84-4 (bundled Tauri + WebKitGTK, libwebkit2gtk-4.1)
• GPU: AMD FirePro W2100 (Oland, GCN 1.0), amdgpu driver, Mesa/radeonsi (also reproduced on a second NVIDIA Quadro FX 380 / nouveau GPU on the same machine)
• Reproduces both on a real physical monitor (local X session, display :0) and over an xrdp virtual session (independent Xorg + amdgpu render node)
• Only this app is affected; all other GTK/Qt/Electron apps on the same machine refresh normally

Steps to reproduce

1. Launch the GitHub-Copilot-linux-x64.AppImage on Linux with XFCE/xfwm4
2. Open any chat/session view and interact with it (send a message, wait for streamed response, etc.)
3. Observe that the window does not visually update while it remains focused and static
4. Switch to another window and back (or resize the window by 1px) -> the view immediately shows the correct, up-to-date content

Expected behavior

The app should repaint continuously as content changes, without requiring a focus change or manual resize.

What we already ruled out

We spent significant time isolating this and ruled out the following (none of these changed the behavior):

• --disable-gpu, --disable-gpu-compositing, --disable-software-rasterizer
• Full software rendering: LIBGL_ALWAYS_SOFTWARE=1 + --use-gl=swiftshader + --disable-gpu-sandbox
• --disable-gpu-vsync --disable-frame-rate-limit
• --disable-renderer-backgrounding --disable-backgrounding-occluded-windows --disable-features=CalculateNativeWinOcclusion
• WEBKIT_DISABLE_DMABUF_RENDERER=1, WEBKIT_DISABLE_COMPOSITING_MODE=1 (note: the app already appears to reference WEBKIT_DISABLE_DMABUF_RENDERER internally per strings in the binary)
• GDK_GL=disable, GDK_DEBUG=no-vsync
• NO_AT_BRIDGE=1 (disabling AT-SPI/accessibility bridge)
• Disabling xfwm4 window manager compositing entirely
• Disabling the X11 Present extension server-side (Option "Present" "Disable" in xorg.conf), tested with a completely fresh X session

Diagnostic clue

Manually forcing a 1px window resize via xdotool windowsize (without any focus change) forces exactly one repaint, then the window goes stale again. This suggests the WebKitGTK UI process is not being told to continuously repaint as content changes — some frame-invalidation/redraw signal from the web content (or from Tauri's event loop) to the native GTK window is not propagating on this system, and only an externally generated ConfigureNotify/Expose or focus event triggers a single forced repaint.

We currently work around this with a script that periodically nudges the window size by 1px every ~0.3s via xdotool, which does force continuous (if slightly laggy) repaints — confirming this is a repaint-signaling issue, not a rendering-capability issue.

Additional context

App logs show no rendering errors; only benign unrelated warnings (libcurl-gnutls symbol mismatch, libdconfsettings.so GIO module load failure, atk-bridge "get_device_events_reply: unknown signature").

Start by reproducing the issue with the Linux AppImage on XFCE/xfwm4 and inspect the Tauri/WebKitGTK repaint path. Confirm that chat or session changes remain invisible until focus or a 1px resize, and that the fix allows updates without external window events.