Skip to content

[Bug]: HUD renders but accepts no input at all on Windows 10 (Store/MSIX build) — global shortcut also inert #385

Description

@Thouby17

Search existing issues

  • I have searched the existing issues

Describe the bug

The HUD window appears and renders correctly, but no input reaches the app at all.

Clicking any HUD control does nothing: source selector, mic, camera, settings, cursor, record, minimize, close. The "Use your system language?" notice appears — so the renderer is alive and locale detection ran — but neither "Keep current language" nor "Switch to Français" responds to a click.

The global shortcut Ctrl + Shift + O (openApp) is inert as well, so this is not limited to pointer input.

The app has to be terminated through Task Manager, since the close button does not respond either. This reproduces on every launch.

Note: in the screenshot, the area surrounding the HUD bar renders opaque black rather than transparent. That may be relevant.

Expected behavior

Clicking a HUD control triggers its action, and the system-language notice can be dismissed or accepted.

To Reproduce

  1. Install OpenScreen 1.9.5 from the Microsoft Store on Windows 10 x64.
  2. Launch the app.
  3. Click any HUD control, or press Ctrl + Shift + O.
  4. Nothing responds.

Screenshots

No response

OS

Windows

OS Version

Windows 10 (x64)

Other OS

No response

Browser

None

Browser Version

No response

Other Browser

No response

Device Type

None

Other Device

No response

Additional context

Install source: Microsoft Store (MSIX)
Version: 1.9.5.0
Install path: C:\Program Files\WindowsApps\EtienneLescot.OpenScreen_1.9.5.0_x64__hedpjctvqwhq0\app

I have not built the app myself, so the following is inference from reading the source rather than a confirmed diagnosis. Ignore anything that doesn't hold up.

  1. Input transparency may be stuck on. The HUD window is created with setIgnoreMouseEvents(true) (electron/windows.ts:491) and only becomes clickable again when a pointermove event lands on an element carrying data-hud-interactive — see handleRootPointerMove in src/components/launch/LaunchWindow.tsx:720. If those forwarded move events never arrive, every click passes through and nothing can re-enable input. Moving the pointer away from the bar and slowly back onto it does not help here.

  2. Transparency itself may be failing. The root container is bg-transparent, but the region around the bar renders solid black on this machine. If the transparent layer is failing on Windows 10, the result would be an opaque 820x560 window that is also configured to ignore mouse events — which matches the symptoms.

  3. The global shortcut registration may have failed silently. electron/globalShortcut.ts:58 only logs a warning when globalShortcut.register returns false, so a failed registration is invisible to the user. That could be an independent cause of Ctrl + Shift + O being inert, or a second symptom of the same root cause.

  4. MSIX packaging may be a factor. electron-builder.json5 documents a prior Store-only failure where MSIX resolved DLLs through the package graph rather than PATH, so the 1.9.0 Store build loaded no compositor at all. That format has produced defects invisible in the NSIS build before.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions