ConnectionPool.reconcileViews re-focused a repaired connection whenever
focusedId named it, but a same-tab sidebar preview moves the keyboard
into the sidebar without ever calling setFocus (multiview.ts's
syncFocus skips it while previewing) — so focusedId keeps naming the
pane the operator was in before the preview, even though the DOM
doesn't agree. Replacing that pane's connection during exactly that
window called onMount({focus:true}) and yanked the keyboard back out
of the sidebar mid-navigation.
Capture existing.el.contains(document.activeElement) before dispose()/
el.remove() detach it (afterward the browser has already moved
activeElement to <body>, too late to tell), and require both that and
focusedId===id to re-focus. document.body and a null activeElement
both naturally fail .contains(), so "nothing focused" and "focus
elsewhere" both correctly skip.
Regression tests: 3 new (real-focus requirement, same-tab preview
race, descendant focus, body-as-unfocused) — 498 tests total.
Three more fixes from acceptance review:
- structured.ts's header omitted the .sessions-btn attach.ts's terminal
header carries. The sidebar is off-canvas on mobile, so a structured
session had no way to reach it — add the same button and
requestToggleDrawer wiring.
- ConnectionPool.reconcileViews always remounted a repaired connection
with focus:false. If the mistyped pane was the one actually focused,
disposing it dropped DOM focus while `focusedId` still named it. Pass
`focus: this.focusedId === id` instead — `focusedId` only ever names a
real focus (multiview.ts skips setFocus while previewing), so a
preview or a merely-visible split neighbour still comes back
unfocused.
- onMount's deferred requestAnimationFrame focus had no way to tell it
had been superseded by an unmount (or a remount elsewhere) before it
fired, so a parked pane could steal focus a frame later. A token
bumped on every mount/unmount lets the callback recognize it's stale
and no-op.
Regression tests: 7 new (structured.test.ts, connections.test.ts). 495
tests total.
Three fixes from acceptance review:
- ConnectionPool.mount cached a connection's kind (terminal/structured)
permanently from whatever `info` it saw first. A deep link or restored
layout mounts before the catalog snapshot names a session's view, so
`info` is undefined and a structured session got an xterm connection
forever. The pool now tracks the view each cached connection was built
for, subscribes to the catalog itself, and replaces a mistyped
connection in place the moment the real view resolves — without
downgrading a resolved connection just because a later caller couldn't
resolve the session, and without treating a session merely absent from
a snapshot (mid-removal) as "Terminal".
- The approval card offered all three decisions unconditionally. Per
the daemon's decision mapping (session.rs's permission_outcome), a
decision with no matching PermissionOptionKind in the request's own
options resolves Cancelled silently — so "Allow for session" could
look like it worked while the daemon withdrew it. Buttons are now
gated on the options actually offered.
- Clicking a decision disabled the buttons and never re-enabled them if
the POST failed. The decision path is async now: a rejection restores
the buttons and surfaces the error only if the approval is still the
pending one — a superseded/resolved approval's stale rejection is a
no-op, not a wrongly revived control.
Regression tests: 12 new (connections.test.ts, structured.test.ts,
structuredRender.test.ts). 488 tests total.
Header name/command were baked into innerHTML at connection creation
and never revisited. ConnectionPool.mount() reused the cached
connection on later calls but dropped the fresh info, so a header
never picked up haiku autoname's rename.
The global listener already ran in the capture phase, but deferred to
isTypingTarget, so xterm's hidden textarea kept Ctrl-K. The bar now treats
that textarea as not a typing target, while real form fields — the spawn
form's inputs — keep their own Ctrl-K.
Leader then ctrl-k (ctrl-a ctrl-k) sends the literal 0x0B to the focused
pane through the leader chord the command set already resolves, so
readline's kill-to-end-of-line stays reachable. The pool grows a
sendToFocused for it, over a new AttachConnection.sendInput.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A session's rail glows AwaitingInput even after the operator has already
looked at it. Clients now report pane focus (POST /:id/focus); the daemon
clears the glow to Idle after 5s of continuous focus and keeps it cleared
until the session does new work, so a fresh Active cycle is required to
glow again.
Miguel Palhas