Skip quiet-settle for occluded panes so parked renderers can't fake completion#123
Merged
Conversation
…ompletion Since #115 parks an occluded surface's renderer, hidden panes emit no render/scrollbar heartbeats. The status indicator's quiet-settle read that silence as "command finished" and flipped a still-running TUI in a hidden tab to a done checkmark — which sticks, because activity events can never revive a done pane. Settle now runs only while the pane's window is visible. On the occluded-to-visible edge the quiet window restarts, so a still-running program gets its heartbeats back before the 3s settle can fire. The occlusion probe is an injected closure (no window = occluded, covering incubator-hosted panes) so the behavior is unit-tested.
github-actions
Bot
added
area:state
The tick-based tests raced the parallel runner: they toggled the shared Preferences.showTabStatusIndicator singleton and drove the whole refreshAllForegroundProcesses path (which also re-reads a live surface's foreground pid — nil under test — clearing the run source). CI's clean UserDefaults + parallel scheduling surfaced the flake the local run hid. settleIfVisible is now internal and tested directly with an injected paneIsOccluded closure: no global mutation, no surface dependency, and a truer unit of the guard this PR adds.
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
1 participant
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.
What
Quiet-settle (the status indicator's "running → done after 3s of silence" transition) now only runs for panes whose window is actually visible, with a fresh quiet window granted on the occluded→visible edge.
Why
#115 parks the renderer of occluded surfaces, which suppresses the render/scrollbar heartbeats that keep an activity-sourced
.runningstate alive. The settle logic read that suppressed silence as completion: runbtopin a tab, switch away for 3 seconds, and the sidebar shows a done checkmark for a program that's still running. Worse, the checkmark sticks —markTerminalActivitydeliberately never revives a.donepane (pinned by TerminalExecutionTrackerTests), so the false state survives until user interaction.Follow-up identified during the #110/#111/#115 review cycle.
How
AppState.refreshAllForegroundProcessesconsults an injectablepaneIsOccludedclosure (default:pane.nsView?.window?.occlusionState; no window counts as occluded, which covers incubator-hosted panes) and skips settle while occluded.TerminalExecutionTracker.refreshActivityWindowrestarts the quiet window — without this, the first visible tick would settle instantly off the stale timestamp and the false.donewould stick.Verified
mise run format,mise run lint, andmise run testall pass🤖 Generated with Claude Code