fix(tabs): stop a tell from a popped-out partner hijacking the main window

Reported from the field: a new tell from someone whose tab is popped out
throws the main window onto the General tab, every time.

The router revealed the tab by activating it in the main window. That
window does not display a popped-out tab -- PickMainActiveTab re-anchors
on the next frame, and it anchors to the FIRST non-popped tab in list
order, not to the one the user was reading. So the reveal did nothing it
intended and threw away the active tab on the way.

Nothing needed revealing in the first place: the tab was already on
screen in its own window. That decision now lives in PlanTellReveal,
next to the pop-out helpers it belongs with, pure and pinned by nine
facts -- the mode, the switch and the popped-out state have eight
combinations between them and only two of them should touch anything.

ActivateTab refuses a popped-out tab outright as well. The router is the
caller that got it wrong, but the invariant belongs to the window: its
active tab is never one that something else is drawing.
This commit is contained in:
2026-08-18 22:25:23 +02:00
parent 4f4f5fc86a
commit 9b634f54e9
3 changed files with 69 additions and 26 deletions
+8
View File
@@ -162,6 +162,14 @@ internal sealed class MainWindow : Window, IFocusableChatWindow
// header pick strips tell-state and resets unread the way a real click does.
internal void ActivateTab(Tab tab)
{
// A popped-out tab is not a surface this window owns. Taking it as
// active does not show it -- PickMainActiveTab re-anchors on the next
// frame, and it anchors to the first non-popped tab, which is not the
// one the user was reading. Callers that mean "bring it forward" have
// to reach for the pool instead.
if (_pool.IsOpen(tab.Identifier))
return;
if (ReferenceEquals(_activeTab, tab))
return;