[johnmatthewtennant]

Why

Opening a channel whose thread pane is open no longer marks the channel read. Buzz reads only in the focused surface, and returning to a channel with a visible selected thread moved focus to that thread's tab and skipped main composer autofocus, so the thread was read but the channel's own messages stayed unread until you clicked into them. This is a bug fix for the channel visit contract: opening a channel reads what it shows.

What

Returning to a channel focuses the main composer again. While focus stays anywhere in that channel's workspace, its visible selected side-pane thread is also a reading surface, so both the channel and the open thread are read. A collapsed pane, another channel's tab, a members or media-review view, and passive restoration still leave the main conversation as the only reading surface. Pane motion completion still wakes observation. A thread in the main pane reads only while focus is inside it.

Only a plain channel visit reads the open thread this way. A link to a message or thread reads only what it focuses. A thread opened from a link or Activity takes focus once its pane shows it, including when the pane was collapsed on that thread or the thread was already selected in the main pane.

Reviewer-reproducible examples

tests/browser/thread-unread.spec.mjs, "returning to a channel reads it and its already-open thread" (1440 px and 1280 px), drives the production UI and read-state engine against isolated relay fixtures: a channel with unread top-level messages and an unread reply in its open thread, switch to another channel, then explicitly return with the pane open.

• On main, in Chromium and WebKit, focus lands on the thread tab instead of the main composer, and the thread dot clears while the channel stays unread (its count remains 18 above the unopened neighbor thread's).
• With this change, the main composer has focus and both clear after reading dwell, while the unopened neighbor thread keeps its dot.

The collapsed-pane case still leaves the hidden thread unread.

Four more regressions in the same file, each failing on the previous head and passing here, in Chromium and WebKit:

• "opening a message link reads the channel but not its already-open thread": a link to a top-level message reads the channel, and the selected thread beside it stays unread.
• "opening a thread from Activity reads it when its channel's pane was collapsed": with Alpha's pane collapsed on Thread root 1, open it from another channel through Alpha's Activity popover. Previously focus stayed on the document body and the thread stayed unread; now the thread tab has focus and the thread reads.
• "a live reply in a main-pane thread stays unread while focus is in the side-pane thread": with Thread root 1 moved to the main pane and Thread root 0 in the side pane, return to Alpha, select Thread root 1, focus Thread root 0's reply composer and deliver a reply to Thread root 1. It stays unread.
• "opening a main-pane thread from Activity reads it, not the side-pane thread": with Thread root 1 already selected in the main pane and Thread root 0 in the side pane, reopen Thread root 1 from Alpha's Activity popover. Previously Thread root 1 stayed unread; now it reads and Thread root 0 stays unread.

Screenshots

After returning to Alpha with Thread root 1 open, from the regression on this build: the main composer has focus, Thread root 1 has no unread dot, and the unopened Thread root 0 and Broadcast reply keep theirs, which is why Alpha keeps its sidebar dot.

🤖 Generated with Claude Code

[loganj]

🤖 Larry and Rbot: an independent adversarial review of 812c492. Source review only. Hosted checks were green; neither of us ran the browser specs locally.

Approving. The visit contract now matches the thread discussion. A plain visit puts focus back in the main composer and also reads the open side-pane thread. A link reads only what it focuses. A main-pane thread reads only with focus inside it. We traced the guards: inactive tab panels stay inert and aria-hidden, so the workspace grant cannot read covered tabs. routedThread needs requestedMessage, so a plain visit keeps composer autofocus. requestedMessage comes from the navigation target, so a message link does not start reading the side thread later in the same visit.

Two optional comments below. Neither is must-fix.