Repository navigation
Start a startup terminal while Orca's window is hidden instead of waiting for it to be shown - #28351
Conversation
… the window is hidden A startup pane waits for its grid to stop changing, counted in animation frames, so a TUI isn't drawn at a transient size. A covered or minimized window produces no frames, so the launch waited until Orca was visible again. Skip the settle while the window is hidden, as hidden panes already do, and end an in-flight settle when the window becomes hidden.
Status: ready for reviewThe problem. A new terminal that runs a startup command, such as an agent from "+", waits for its size to settle. That wait counts screen refreshes. A covered, minimized or hidden Orca window gets no screen refreshes, so the agent started only when Orca was visible again. Meanwhile "+" showed a false "Couldn't launch Claude — the terminal did not start." toast. User-facing change. Agents from "+" now start while Orca is covered or minimized, and the false toast is gone. Visible windows keep the startup wait from #6940, so nothing changes for them. Review. Round 1 used two reviewers: a fresh Claude reviewer, and a Codex reviewer that also sketched its own design before reading this one. Neither found a proven issue. The Codex reviewer accepted the design: the rule sits where the startup wait is decided, it reuses the app's existing window-visibility check, and the listener for a window hidden during the wait is needed. Deferred items (not changed):
Fixed during the loop. CI's changed-code gate flagged two new type casts in the test. They were replaced with one cast that carries a stated reason (c74b8b1). Live QA (macOS, main build vs this PR, test window never shown on the desktop):
The first QA pass hit a test-window artifact: a click while the test window was already marked hidden made Orca treat it as visible. That pass was rerun from a clean visible window with no input while hidden. The real agent config files were checked by hash before and after every run and did not change. Readiness.
Not verified. Linux and Windows were not tested live. The case where a window the OS reports as visible slows its screen refreshes (seen in earlier Windows test runs) is out of scope. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ➖ Normal Merge Risk: ⚪ Minimal · up to
|
ELI5
When you start an agent from the "+" menu and then switch to another app (so Orca is covered or minimized), the agent doesn't start until you come back to Orca. While it waits, Orca shows a false error: "Couldn't launch Claude — the terminal did not start." This PR lets the agent start right away even when Orca isn't on screen.
What Changed
The problem. A new terminal that runs a command at startup (an agent from "+", for example) first waits until the terminal's size stops changing, so the agent isn't drawn at a temporary size and left with leftover drawing on screen. This wait was added by #6940 ("Fix Codex skill preview terminal artifacts"). It counts screen refreshes (animation frames). A covered, minimized or hidden Orca window gets no screen refreshes, so the count never moves and the terminal never starts until Orca is visible again. Measured on main: "+" > Claude in a covered window started only when it was uncovered (about 65 s later), and in the meantime showed the false "terminal did not start" toast.
Panes that are hidden inside Orca (a background tab) already skip this wait. A hidden window gets nothing from the wait either: nothing is painted, so there is nothing to keep clean.
User-facing change.
Mechanism (
pty-resize-geometry.ts):getWindowParkVisible), which also handles the macOS case where the window wrongly stays marked hidden after display sleep.Size while hidden. Measured on a main build with the window hidden (no screen refreshes): a new terminal measures 135×58, the same as when visible. So the terminal starts at its real size; no fallback size is needed. The wait's own measurement uses the same fit.
Why
The wait exists only to avoid visible drawing glitches, and a hidden window draws nothing. Extending the existing hidden-pane skip to the hidden window is the smallest change that removes the stall. A time limit on the wait was rejected: it would still delay every hidden launch, and it puts a guessed number on something the window's visibility already tells us.
Limits (what this does not change):
Linked Issue
None (maintainer change). It lands before #28209 and #28210, which make AI-button tabs start their agent in their own terminal and so put them on this same startup wait.
Visual Proof
Hidden test window, "+" > Claude clicked while the window was hidden. Screenshots taken after the window was shown again.
Testing
pnpm tc:web, oxlint on the changed files.Not verified
Linux and Windows were not tested live; the change reuses the same cross-platform visibility check other parts of the app already use.
Not reproduced, from review: the macOS case above, where a window is wrongly marked hidden, but before any click or key press. A launch with no input in that state would skip the startup wait (about 100–200 ms of screen refreshes). A click or shortcut launch is itself input, so it does not hit this case.
Deferred test nit: the "hidden during the wait" test does not check that the visibility listener is removed.
I manually tested these changes locally
Automated tests added/updated, or explained why not below
AI Disclosure
Review
Agent skill upstream boundary
Notes
Checklist
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)