Sidebar tab highlight is not always correct in shell sessions

[mortenaslo]

Bug

When the active session is a shell session, the corresponding sidebar tab is not always highlighted correctly to reflect which session has focus.

Expected

The sidebar entry for the active session should always be visibly highlighted (the active-ring/selected state) so it's clear which session is currently focused.

Actual

For shell sessions, the sidebar highlight occasionally doesn't follow the active session — the wrong tab appears highlighted, or no tab appears highlighted at all.

Notes

The active-terminal highlight is driven by UpdateActiveTerminalHighlight / UpdateSidebarActiveState (called on every MainViewModel.ActiveSession change). Worth checking whether the sidebar-side path runs in all the same scenarios as the terminal-ring path, especially for sessions launched as raw shells vs. Claude sessions.

[AThraen]

Likely fixed by #93 + #106 — worth re-testing before doing any work here.

The root cause described in this issue matches what #93 found: MainViewModel.ActiveSession only ever moved on a sidebar click. There was no focus or click handler on the WebView2 at all, so clicking straight into a pane and working in it left the highlight on whatever row was last selected in the sidebar.

That also explains the "for shell sessions" part. A Claude session raises alerts, and AlertDetector/NotifyUserInteracted churn kept nudging the sidebar state; a plain shell produces none of that, so the stale highlight just sat there.

Now clicking or typing in a pane promotes it (#93), and #106 corrected that to fire on real key events only — an earlier attempt promoted on any PTY input, which mouse movement and terminal replies also trigger.

Both are on main but not yet in a release. Please re-check against a build from main; if the highlight still lags for shell sessions specifically, that's a different bug and this issue should stay open with the new detail.

[AThraen]

Shipped in v0.7.0 — closing

Correcting my own earlier comment: it said the fixes were "on main but not yet in a release". All three are in v0.7.0 (tagged 2026-09-06):

PR	Commit	What it did
#93	5c9b955	Clicking or typing in a pane makes it the active session — previously MainViewModel.ActiveSession moved only on a sidebar click
#106	87798c4	Promote on real key events only. #93 fired on any xterm onData, which also carries device-attribute replies, cursor-position reports and focus in/out — those made the highlight move on its own
#108	c4f3985	Do the click promotion from the page. WebView2 is an HwndHost, so mouse input landing on the hosted content raises no WPF routed events at all — a PreviewMouseLeftButtonDown on the host Border only ever fired for the thin ring around the terminal

The root cause matches this report, including the "for shell sessions" qualifier: a Claude session raises alerts, and the AlertDetector / NotifyUserInteracted churn kept nudging sidebar state back into agreement. A plain shell emits none of that, so the stale highlight simply sat there.

Closing as fixed. If the highlight still lags on a v0.7.0-or-later build — specifically for shell sessions, after clicking straight into a pane without touching the sidebar — please reopen with the build number; that would be a different bug from the one #93/#106/#108 fixed.