- Ya
- 2 Septemba 2026, 02:36 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 9d77470
Maximizing a chat popup left the conversation navigator on whatever tab it was already showing. `visibleRows` drops every row outside the active bucket, so the conversation the member had just put on screen was filtered out of the list beside it — and with no row to render there was nothing to mark as the selected one either. Two things stacked to cause it. `ChatSwitcherColumn` froze its bucket seed at the first toolId it ever saw, so a swap that changed which window holds the pane could not move the tab; and `initialBucket` could not have fixed that anyway, because it is read once into `useState` and the saved `chatSwitcherActiveBucket` preference overrides it — so from a member's first tab click onward, the window's own type had stopped being consulted for good. The seed is replaced by a live `followBucket`: the bucket holding the conversation on screen, which beats the saved preference because it is not a guess about where the member would like to start, it is a fact about what they are reading. It is applied to the seed AND inside the preference restore rather than by an effect afterwards, so the right bucket is loaded once instead of flashing through the saved one — the property cases 6a/6b already guard. The freeze was there for a reason, and that reason is kept. A chat window can only ever name 'teamMembers'; whether a CHAT session is filed under teamMembers or members is decided by the counterpart's memberType, which lives on the row and not on the window. So `bucketFollowing` decoders a follow inside that one family, and a member reading Members is left where they are when they click a row there.