[joelrobotham]

Problem

With a thread already open and selected, hovering its mention in sidebar Activity and clicking it did not clear the unread dot. With the thread closed, the same click did.

Cause

A thread is marked read only by the reading observer (use-reading.ts), which requires focus inside the thread's reading surface. Opening a closed thread adds and selects a tab, and PanelWorkspace focuses it. Opening an already-selected thread changes no selection, so nothing hands focus in, and the click leaves focus on the sidebar/popover.

Fix

ThreadMessages focuses its scroller when it receives a new navigation request that addresses its own thread root, but only when nothing holds focus (the opener's control has unmounted). It does nothing if the opener asked to preserve focus, the panel is inactive or not yet positioned, or the person has focused anything else in the meantime. That covers both a pending retarget (review feedback) and a first opening whose routed request arrives after the panel opened.

The Activity popover no longer returns focus to its sidebar trigger after an unread-thread row opens a thread. Base UI returns focus in a microtask after close, and when the popover unmounted in the same commit as the navigation, that microtask stole focus from the thread. This uses the same finalFocus={() => !handoff.current} pattern as ProfileButton.

Production diff: ThreadPanel.tsx and ChannelActivityPopover.tsx.

Tests

• New browser journey in thread-unread.spec.mjs: open a thread with reading focus held, click the same thread from Activity, expect observed unread to reach 0. Fails on main (stays 1), passes with the fix, twice each way.
• Chromium: thread-unread, activity-navigation-focus, channel-tabs — 13 passed. Vitest for ThreadPanel / ChannelsPage.tabs / ConversationTab / ChannelActivityPopover — 128 passed. tsc --noEmit and biome lint/format clean on touched files.

Manually verified with a local run of the app.

Additional tests and CI notes

• thread-unread.spec.mjs: new case "an Activity reopening leaves focus the person moved meanwhile". It holds relay reads, reopens the thread from Activity, and types in the channel composer while the reads are held. Fails 6/6 on 1bec7851 (Chromium + WebKit) and passes 6/6 with the fix.
• Before the fix, the Activity test failed 2 of 100 locally in Chromium (popover return-focus race), and navigation-thread-history:20 failed 26 of 40 in WebKit with 4 workers. With the fix: Activity test 150/150 Chromium (instrumented), 50/50 Chromium, 49/50 WebKit (the one failure was a setup timeout in Search Buzz). navigation-thread-history:20: 40/40 WebKit. Related suites in both engines: 160/160.
• Unrelated test change: github-body.spec.mjs:35 failed on every CI run of this PR in Linux WebKit. Its fixture clip is 2 s long, and the "Pause video" click waited about 2 s for the button to stop moving. By then the clip had ended, the button had become "Play video", and the click restarted playback, so the next "Play video" button looked up by position didn't exist. Each video now uses its own player's controls and plays to the end. Pause clicks remain covered by the video player tests and messages.spec.mjs. Not reproducible on macOS. I have not found why it only failed on this PR.

[salman1993]

🤖 Reviewed commit 1bec785. One P2 correctness finding below. Validation: 34 existing browser checks across Chromium and WebKit and 100 focused unit tests passed. A separate gated focus-ordering reproduction fails in both engines with this change and passes with only the new effect removed. Native desktop acceptance was not exercised.

[salman1993]

🤖 [P2] Preserve newer focus intent while the retained thread retargets

Reopening an already-open thread from Activity waits for RetainedThreadPanel's async view.retarget() before this effect receives the new navigation. If the user clicks into the channel composer and starts typing while the root/overlay reads are pending, this guard accepts that newer focus and moves it into the thread scroller when the reads finish, interrupting typing. I reproduced this with an explicitly gated root read in both Chromium and WebKit; the same scenario passes with only this new effect removed. Capture the opening focus intent before awaiting retarget and expire the handoff on subsequent pointer/keyboard input, following the existing usePendingRequest policy.

[joelrobotham]

Thanks, reproduced and fixed in 5809530, with a regression test in 89bf94c.

Test (thread-unread.spec.mjs, "an Activity reopening leaves focus the person moved meanwhile"): it holds relay reads, opens the already-open thread from Activity, and types in the channel composer while the reads are held. After the reads are released and navigation reports opened, it checks that the composer still has focus and still contains the text.

• On 1bec785: fails 6 of 6 (Chromium and WebKit, "Received: inactive").
• On 89bf94c: passes 6 of 6.

Fix: the handoff now moves focus into the thread only when nothing holds focus (activeElement is body). That is the state an Activity row leaves behind when the popover unmounts it. Focus the person placed anywhere else is no longer taken, whether during a pending retarget like here or just after a first opening whose routed request arrives late. The late-request case was also breaking navigation-thread-history:20 in WebKit under load.

Same commit: the Activity popover no longer returns focus to its sidebar trigger after a thread row opens a thread. That uses the finalFocus={() => !handoff.current} pattern from ProfileButton. Base UI's return-focus microtask could run after the thread took focus and steal it, which caused the intermittent CI failure of the Activity test.

Not done: expiring the handoff on pointer/keyboard input the way usePendingRequest does. With the body-only rule, that would add just one case: a click on a non-focusable area during the reads. That leaves nothing focused, so the thread that was asked for takes focus. Covering it properly means starting the listener before retarget and passing the result down. Happy to add it if you think that case matters.