Description
On Linux (Fedora, Wayland session), dragging the HUD recorder bar by its 6-dot grip handle does nothing — the window doesn't move. Dragging by the dark border around the bar works fine. Attempting to drag the grip handle throws a JavaScript error.
Environment
- OS: Fedora Linux 44 (Workstation Edition) x86_64
- Kernel: Linux 7.1.3-201.fc44.x86_64
- DE: GNOME 50.3
- Session: Wayland
- App: Openscreen v1.6.0 (AppImage)
Steps to reproduce
wget https://github.com/getopenscreen/openscreen/releases/download/v1.6.0/Openscreen-Linux-1.6.0.AppImage
chmod +x Openscreen-Linux-1.6.0.AppImage
./Openscreen-Linux-1.6.0.AppImage
- Launch the app from a terminal.
- Try to drag the HUD bar by clicking and pulling on the 6 dots (grip handle) to move it around the workspace. It doesn't move.
- Try instead dragging by the dark border around the HUD bar — this works.
- Repeat step 2 (drag the dots) — a JavaScript error appears.
Terminal output
[14647:0720/221319.006118:ERROR:content/browser/browser_main_loop.cc:290] Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Failed to register global shortcut: CommandOrControl+Shift+O
[14647:0720/221319.665735:ERROR:content/browser/browser_main_loop.cc:290] Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
[14647:0720/221334.299183:ERROR:content/browser/browser_main_loop.cc:290] Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
[14647:0720/221349.171167:ERROR:content/browser/browser_main_loop.cc:290] Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Root cause
The grip handle repositions the HUD via a custom pointer-capture drag that calls BrowserWindow.setPosition() (IPC channel hud-overlay-move-by in electron/windows.ts). Wayland compositors don't let clients reposition their own top-level window outside of an OS-initiated interactive move, so setPosition() is effectively a no-op there. The border drag works because it uses native -webkit-app-region: drag, which goes through the compositor's own move gesture instead.
Description
On Linux (Fedora, Wayland session), dragging the HUD recorder bar by its 6-dot grip handle does nothing — the window doesn't move. Dragging by the dark border around the bar works fine. Attempting to drag the grip handle throws a JavaScript error.
Environment
Steps to reproduce
Terminal output
Root cause
The grip handle repositions the HUD via a custom pointer-capture drag that calls
BrowserWindow.setPosition()(IPC channelhud-overlay-move-byinelectron/windows.ts). Wayland compositors don't let clients reposition their own top-level window outside of an OS-initiated interactive move, sosetPosition()is effectively a no-op there. The border drag works because it uses native-webkit-app-region: drag, which goes through the compositor's own move gesture instead.