[Bug]: Recording HUD bar oscillates/vanishes on mouse hover on Arch Linux (Hyprland / Wayland)

[itshimelz]

Search existing issues

• I have searched the existing issues

Describe the bug

When launching the Recordly AppImage (v1.3.3) on Arch Linux running Hyprland (native Wayland, ELECTRON_OZONE_PLATFORM_HINT=auto), the floating recording HUD control bar instantly disappears, flickers, and becomes unclickable as soon as the mouse cursor hovers over it.

Expected behavior

The recording HUD should remain stably positioned and interactive when hovered, allowing users to click record, toggle microphones/cameras, and access settings without jumping or vanishing.

To Reproduce

1. Run the Recordly AppImage on Arch Linux under Hyprland (native Wayland session, xwayland: 0):

   ./Recordly-linux-x64.appimage

2. The pill-shaped recording HUD appears floating on screen.
3. Move the mouse cursor over any button on the floating recording bar.
4. The recording bar immediately jumps out from under the pointer, collapses, and enters a rapid oscillation loop, appearing to vanish or flicker uncontrollably.

OS

Linux

OS Version

Arch Linux, Hyprland 0.56.2 (Wayland)

Additional context

Technical Root Cause

• In recordly_main.cjs / electron/windows.ts, mouse passthrough is disabled on Linux (zt() === false).
• On mouse enter (handleHudMouseEnter), the renderer requests hudOverlaySetIgnoreMouse(false), triggering W_(true).
• W_(true) attempts to expand the HUD window bounds from 160px to 540px height via setBounds to prepare room for popups, simultaneously calculating new_y = old_y - 380px to keep the bottom aligned.
• Under the Wayland protocol (xdg_toplevel), compositors do not permit clients to position their own absolute screen coordinates (x, y). Hyprland anchors/centers the resizing surface and ignores the requested y repositioning.
• Because the React UI layout is anchored to the bottom (items-end pb-5, height: 100vh), the 380px downward expansion pushes the control bar 380px away from the mouse cursor.
• The pointer is no longer hovering the bar, firing handleHudMouseLeave, which triggers W_(false) and shrinks the window back to 160px.
• Shrinking brings the bar back under the cursor, triggering handleHudMouseEnter again, causing an infinite oscillation loop.

Related Issues & PRs

• Relates to [Bug] Crazy movements when hovering #600, AppImage HUD flickers and becomes unclickable on Niri (Wayland) #772, Fix HUD menus and cursor telemetry on Linux Wayland (Hyprland/Omarchy) #860, Fix HUD menus and cursor telemetry on Linux Wayland (Hyprland/Omarchy) #863, and Fix Linux Wayland HUD oscillation on hover and popover menu clipping #876.

Workaround

Running with XWayland prevents the issue because X11 permits client-side (x, y) coordinate placement:

ELECTRON_OZONE_PLATFORM_HINT=x11 ./Recordly-linux-x64.appimage

[AlexSilva-dev]

Confirmed on the same stack (Arch, AMD Lucienne, Hyprland 0.56.2, XDPH 1.4.1) with the v1.4.0-beta.1 AppImage: the HUD window stays at its mapped size when the menu opens — the popover renders inside the 860x160 window bounds and everything above the bar is clipped.

Instrumented window tracking shows the fallback expand (hud-overlay-set-menu-open → setHudOverlayFallbackExpanded) never takes effect on Wayland — Hyprland ignores the client-side resize, consistent with the note in hudOverlayBounds.ts ("Wayland refuses client-side window placement").

Workaround that fully unblocks recording on Hyprland while this is open — pin the HUD to the bottom-center of the screen with a windowrule so the popover has room above the bar:

windowrule = move 50%-w 100%-h-60, match:class ^[Rr]ecordly$, match:float 1

(Also ran into the save-hang from the evdev blocking reads on this stack — opened #904 with a non-blocking rewrite, details there.)