Repository navigation
[Bug]: Cant use the record UI #266
Description
Search existing issues
- I have searched the existing issues
Describe the bug
cant click or do anything, in the task manager is show but when i press windows + tabs not show anywindows is like a ghost
Expected behavior
i will be fixed
To Reproduce
just open after install
Screenshots
i cant use anything, click, drag,... i use 1.8.0. Is show on task manager
when i press alt+tab:
OS
Windows
OS Version
No response
Other OS
No response
Browser
Chrome
Browser Version
No response
Other Browser
No response
Device Type
Desktop
Other Device
No response
Additional context
No response
Activity
EtienneLescot commentedon Aug 5, 2026
@LuniteLang-Sys Thanks for the report.
Does Ctrl+Shift+O unlock the situation ?
LuniteLang-Sys commentedon Aug 5, 2026
nope is not fix
LuniteLang-Sys commentedon Aug 5, 2026
i can click through the windows btw
LuniteLang-Sys commentedon Aug 5, 2026
is like ghost windows
chelsiemeye commentedon Aug 5, 2026
same issues here
fix(hud): stop being born click-through, wait for the renderer to ask
test(hud): pin that click-through is asked for, never born with
docs(hud): replace the guessed exposure window with a measured one
fix(hud): stop being born click-through, wait for the renderer to ask
test(hud): pin that click-through is asked for, never born with
docs(hud): replace the guessed exposure window with a measured one
fix(hud): stop being born click-through, wait for the renderer to ask
test(hud): pin that click-through is asked for, never born with
docs(hud): replace the guessed exposure window with a measured one
EtienneLescot commentedon Aug 10, 2026
Fixed in v1.9.0, by
6eb5bbb7.The HUD asked to be input-transparent twice: once at construction, and once from the renderer's mount effect. The first one is the bug you hit — app running, bar painted, every click and drag dead from the very first launch. That is the "ghost window" you described, and it also explains why Ctrl+Shift+O did not help.
On Windows,
setIgnoreMouseEvents(true, { forward: true })installs a global low-level mouse hook, and that hook is the only route back: Chromium delivers no pointer events to a window it has made input-transparent, so the renderer cannot ask to leave the state it is stuck in. Electron latches the install and only retries after asetIgnoreMouseEvents(false)— the call the dead hook prevents. So one hook that is refused, or that Windows revokes for overrunning the 300 msLowLevelHooksTimeout, bricks the UI with no way out. Construction is the worst possible moment to ask for it, since that callback runs on the main thread while the app is still booting.The HUD is now born clickable, and only becomes click-through when the renderer asks over IPC, on a thread that is provably pumping messages. If that ask never arrives, the bar stays clickable instead of turning into a ghost.
@LuniteLang-Sys @chelsiemeye — closing on that basis, but honestly: it was never confirmed on a machine that actually reproduced it, since we have none. Current release is v1.9.2. If you still get a ghost window there, please reopen and say so.
docs(e2e): say what injected input can never prove about the HUD
docs(e2e): say what injected input can never prove about the HUD
docs(e2e): say what injected input can never prove about the HUD
fix(hud): give click-through a way out that Windows cannot revoke