The command-palette-specific IPC approach didn't cover other modals
with inputs (settings search, playlist creation, etc.). Replace it
with document-level focusin/focusout listeners that signal the main
process whenever any input/textarea/contenteditable gains or loses
focus, so the menu rebuild is triggered automatically for all current
and future input surfaces.
Co-authored-by: muckymucky <muckymucky@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
On macOS, menu item accelerators (e.g. Space for Play/Pause) fire even
when an input has focus, bypassing the renderer-side useHotkeys guard
added in #1925. Typing a space character in the command palette search
toggled play/pause instead of inserting a space.
Track command palette open state in the main process via IPC. When the
palette is open, rebuild the application menu with empty playback
accelerators so single-key shortcuts no longer intercept keystrokes
intended for the search input. Restore accelerators when the palette
closes.
Co-authored-by: Jack McCrea <jack@MacBookPro.lan>
The setDisplayMediaRequestHandler was calling desktopCapturer.getSources()
to provide a video source that the renderer never uses (it requests
video: false and only consumes audio tracks). On Wayland, this created a
new xdg-desktop-portal ScreenCast session on every launch, showing an
unavoidable screen share dialog because Electron does not persist
PipeWire restore tokens across desktopCapturer sessions.
Simplified the handler to return only { audio: 'loopback' }, which
captures system audio via PipeWire/PulseAudio monitor source without
any portal interaction.
In f07393c8 we enabled the MediaSession API, which from Chromium's side
brings its own native way of handling Global Media Keys. However, it
turns out having this enabled seemingly conflicts with Windows 11's SMTC
implementation when we also bind the Media Keys using Electron's Global
Hotkeys API (Windows 10 is apparently fine, but now EOL).
Globally passing `HardwareMediaKeyHandling` to `disable-features` was
considered, however using the MediaSession API requires
`HardwareMediaKeyHandling` to be enabled, so this is not an option.
Instead, with MediaSession enabled we need to let Chromium handle the
Media Keys, while without MediaSession we bind our own Global Hot Keys
for users that have them enabled in the settings.
Co-authored-by: Xudong Zhou <godzmichael@outlook.com>
muckymucky