TerminalApp: foreground target window in FocusProtocolPane#353
Merged
Conversation
focus_pane (Enter on a Live session in the session management view) could fail to surface the target window when that window already had the target pane focused. FocusProtocolPane only moved XAML focus *within* the window via _SetFocusedTab/FocusPane — which no-op when the pane is already focused — and relied on the focus transition as an accidental side effect to bring the OS window forward. Symptom: focusing session1 (in window1) from window2 worked only when window1's focus was on a different pane (e.g. the agent pane), but not when window1 was already focused on session1's own pane. Fix: raise SummonWindowRequested once the target pane is found, mirroring the desktop-notification activation path in TabManagement.cpp, so the window is reliably brought to the foreground regardless of its prior focus state. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes cross-window focus_pane activation so that focusing a protocol pane in another window reliably brings the target OS window to the foreground even when that window already had the target pane focused (i.e., when intra-window XAML focus operations would otherwise no-op).
Changes:
- Raise
SummonWindowRequestedinsideTerminalPage::FocusProtocolPaneonce the target pane is located, ensuring OS-level window activation. - Preserve the existing tab/pane focusing logic (including the stashed agent-pane restore path) after summoning.
vanzue
approved these changes
Jun 24, 2026
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
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.
Summary
Cross-window
focus_pane(Enter on a Live session in the session-management view) could fail to bring the target window to the foreground when that window already had the target pane focused.Repro
Root cause
TerminalPage::FocusProtocolPaneonly moved XAML focus within the target window via_SetFocusedTab/FocusPane. Those no-op when the pane is already focused, and the OS window previously only came forward as an accidental side effect of the focus actually transitioning. When the target pane was already focused, no transition happened → no activation → the window stayed in the background.Fix
Raise
SummonWindowRequestedonce the target pane is found, mirroring the desktop-notification activation path inTabManagement.cpp. The window is then reliably brought to the foreground regardless of its prior focus state.SummonWindow(toggleVisibility=false)→_globalActivateWindowperforms the activation; it is intra-process (the COM server runs insideWindowsTerminal.exe), so noAllowSetForegroundWindowis required.Test plan
0 Error(s);WindowsTerminal.exe+CascadiaPackagelink and pack cleanly.