AppImage HUD flickers and becomes unclickable on Niri (Wayland)

[pikyusufaslan]

Environment

• Arch Linux
• Niri (Wayland, wlroots-based compositor)
• Recordly AppImage

Actual behavior

The small floating recording-control HUD intermittently disappears and reappears. When it is visible, it cannot be clicked, so recording controls are unusable.

Expected behavior

The recording HUD should remain visible and interactive throughout the recording setup flow.

Important comparison

The current upstream source was checked out at 360b160 (the current main tip at the time of testing) and launched with npm run dev in the same Arch + Niri/Wayland session. The HUD remained visible and clickable there; the problem only occurred with the AppImage.

The development launch did emit this Chromium warning:

--ozone-platform=wayland is not compatible with Vulkan. Consider switching to --ozone-platform=x11 or disabling Vulkan

This points to a packaged-runtime / Electron GPU or Wayland launch-path difference rather than the HUD UI flow itself.

Notes

I have not yet captured stdout/stderr from the AppImage itself. I can provide it and a screenshot if maintainers want a particular diagnostic command or build.

[Nuu-maan]

This matches the hover-resize bug in the released AppImages (1.3.1–1.3.3): the Linux HUD window grows on hover and Wayland compositors re-place it, so the bar moves out from under the pointer and flickers. main at 360b160 already had the revert, which is why the dev build behaved. #863 restores menu expansion without the hover trigger; if you can test the branch on Niri, the assumption to check is that Niri keeps the resized floating window centred (Hyprland does).