Fix the desktop app's Linux gaps: window geometry, HUD click-through, and window-read diagnostics - #82201
Merged
Conversation
`moved` and `resized` are macOS/Windows only — Electron tags them `@platform darwin,win32` — so on Linux neither the main window nor the HUD ever heard that it had been dragged or resized, and both reopened at their default placement every launch. The main window had a `close` flush to fall back on; the HUD had nothing, so its position was lost outright. Bind `move`/`resize` instead. Those carry no platform tag and fire everywhere, and the trailing debounce already collapses the mid-drag stream a settled event would have saved us from.
Click-through decides whether to swallow the mouse by hit-testing the document
under the cursor, and it learns where the cursor is from mousemove. Those keep
arriving while the window ignores the mouse only because of
`setIgnoreMouseEvents(true, { forward: true })`, and `forward` is
`@platform darwin,win32`. On Linux the moves stop the instant the HUD turns
click-through, so it never sees the pointer return to the bar: the bar is
visible, and clicking it hits whatever is behind.
Main can still see the cursor, so on Linux it polls and pushes the position to
the renderer, which runs its usual hit test on it. The decision and its rules
stay in one place — only the courier for that one input changes — and off-window
is sent as null, which is already how the renderer hands the mouse back.
When enumeration was impossible the tool answered "could not determine the window underneath (the desktop app did not answer, or window enumeration is unavailable on this system)" — true, and a dead end. On Linux the two ways it fails have opposite fixes and neither is guessable from that: a Wayland session withholds window identity from applications outright, while an X11 session needs xprop and xwininfo installed, because that is what the enumerator shells out to. Answer with the reason instead of nothing. A session with both WAYLAND_DISPLAY and DISPLAY is XWayland, where xprop can still answer, so it gets the tooling advice rather than being told to change session type.
Contributor
૮ >ﻌ< ა ci reviewran on 04afc8d
|
OutThisLife
enabled auto-merge
August 9, 2026 03:23
alt-glitch
added
type/bug
|
@OutThisLife can you pls look into it #75038 |
5 tasks
randlee
pushed a commit
to randlee/hermes-agent
that referenced
this pull request
Aug 11, 2026
Fix the desktop app's Linux gaps: window geometry, HUD click-through, and window-read diagnostics
33hodl
pushed a commit
to 33hodl/hermes-agent
that referenced
this pull request
Aug 12, 2026
Fix the desktop app's Linux gaps: window geometry, HUD click-through, and window-read diagnostics
13 tasks
prmartinow
pushed a commit
to prmartinow/hermes-agent
that referenced
this pull request
Aug 26, 2026
Fix the desktop app's Linux gaps: window geometry, HUD click-through, and window-read diagnostics
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three places where the desktop app quietly depended on a platform-gated Electron API and did nothing at all on Linux. Each is a fix for the whole class rather than the one call site, and each ships with tests over an extracted helper so the platform reasoning is checkable without booting Electron.
Window geometry was never saved on Linux
main.tspersisted window state frommovedandresized, and Electron tags both@platform darwin,win32— they never fire on Linux, so neither the main window nor the HUD ever heard that it had been dragged or resized. The main window had acloseflush to fall back on; the HUD had nothing, so its position was lost outright every launch.Both windows now bind through one
bindGeometryPersistencehelper usingmove/resize, which carry no platform tag. Those fire continuously mid-drag, which is what the existing trailing debounce is already for — so the settled-only events were buying nothing the debounce didn't give us.The HUD was permanently click-through on Linux
Click-through decides whether to swallow the mouse by hit-testing the document under the cursor, and it learns where the cursor is from mousemove. Those keep arriving while the window is ignoring the mouse only because of
setIgnoreMouseEvents(true, { forward: true }), andforwardis@platform darwin,win32. On Linux the moves stop the instant the HUD turns click-through, so it never sees the pointer come back to the bar: the bar is visible, and clicking it hits whatever is behind.Main can still see the cursor, so on Linux it polls and pushes the position to the renderer, which runs its usual hit test on it. The decision and its rules stay in one place — only the courier for that one input changes. The conversion is the fiddly part and is extracted to
hud-cursor.ts: screen space to window space, then DIP to CSS pixels, sincegetCursorScreenPoint()andelementFromPointagree only at zoom 1. Off-window returns null, which is already how the renderer hands the mouse back.read_window_belowfailed without saying whyAny enumeration failure produced "could not determine the window underneath (the desktop app did not answer, or window enumeration is unavailable on this system)" — true, and a dead end. On Linux the two ways it fails have opposite fixes and neither is guessable from that message: a Wayland session withholds window identity from applications outright, while an X11 session needs
xpropandxwininfopresent because that is what the enumerator shells out to.It now answers with the reason. A session with both
WAYLAND_DISPLAYandDISPLAYis XWayland, wherexpropcan still answer, so it gets the tooling advice rather than being told to change session type. The tool schema tells the model to relay the reason rather than retry.Not included
Windows 11 frost via
backgroundMaterialwas investigated and dropped. The material paints the entire window rectangle, and the HUD window is mostly empty space with a bar and a band floating in it — acrylic there frosts a large slab over whatever the user is working in, and it also removes the rounded corners (electron#43075, electron#47510). The CSS fill remains the right fallback on Windows.Test plan
npx vitest run electron/— 930 passed, 2 skippednpx tsc --noEmitclean,eslintclean on all changed filesscripts/run_tests.sh tests/tools/test_read_window_tool.py