fix(inbox): open DM thread rows as the thread - #2587

… showed

Addresses the PR #2587 review (kazemek21, discussion_r4482874961, and
wesbillman's review). With a DM row now opening as its thread, a
top-level DM message arriving later never appears in that thread tab.
The thread's next earned dwell, after refocusing or scrolling, still
read the whole DM: `readDm` advanced the DM's one channel frontier
through the newest retained message, including messages the thread
never displayed. The same happened when returning to Activity restored
the thread tab after a top-level message had arrived meanwhile.
Re-clicking the row repaired navigation (it then opens the whole DM),
but the message had already lost its unread state.

Fix: a reading lease can name the thread its reader shows
(`session.unread.reading(channelId, rootId)`). In a DM, a thread lease's
read stops at one second before the earliest unread message outside
that thread: a top-level message, or a reply in another thread. The
thread's own root and replies, and the viewer's own messages, never
stop it. "Unread" is the same predicate the Inbox projection uses for
the row's `threadOnly`. With nothing unread outside the thread, a
thread read still covers the whole DM, as before. Whole-DM reads (the
DM timeline, which names no thread) are unchanged, and so is the row's
own explicit read on click.

The frontier is one timestamp, so it cannot skip a message. The
thread's own replies from that outside message on stay unread too,
until a whole-DM read covers them. That is deliberately conservative:
the row then holds unread messages outside the thread, so it is no
longer `threadOnly`, and re-clicking it opens the whole DM (the
existing rule that a thread tab follows its row).

Surfaces changed: every DM thread view reads through `ThreadPanel`'s
`useReading`, which now passes its thread to the lease. That covers the
Activity (Inbox) DM thread tab, including a tab restored on returning
to Activity, and the Channels DM thread pane, plus embedded DM threads.
In Channels the DM timeline beside the thread pane still reads the
whole DM when it has focus; only reads earned in the thread pane
alone are now bounded, as a channel thread's catch-up never reads its
channel's timeline. `ThreadPanel` passes the thread it opened while
the root is still unresolved, so a reply visible under an unavailable
root cannot read the whole DM either. Channel and Solo reads ignore
the thread and are unchanged.

Tests:
- unread.test.ts (catchUp and observe): one DM through a thread lease.
  Nothing unread outside: reads all of it. A reply in another thread:
  stops just before it, leaving it and the thread's later reply unread.
  A whole lease then reads everything. The viewer's own top-level
  message does not stop it, but Alice's top-level message does. The
  row then resumes at that message, unread, without `threadOnly`, and
  a further thread dwell still cannot pass it.
- InboxPage.test.tsx (open tab, and tab restored after returning to
  Activity): open a thread-only DM row as "Thread · Alice". Alice then
  replies in the thread and posts at the top level, either while the
  tab shows or while Activity is unmounted. A focus dwell in the thread
  history must read the new reply but stop the frontier one second
  before the top-level message. The row stays unread, previews and
  resumes at that message, and re-clicking it opens the whole DM. jsdom
  has no layout or window focus: the test lays out thread history alone
  (so the opened thread's reveal completes and it settles, as a real
  layout lets it) with the window unfocused, so nothing reads until the
  dwell focuses the window and the history and runs a controlled clock
  until the read lands. A fixed 300 ms window raced the settle, which
  depended on a leftover reveal frame (1 in ~8 full-file runs).
- ThreadPanel.test.tsx: with the original unavailable, every reading
  lease names the thread the panel opened.
- use-reading.test.ts: leases now carry `(channelId, rootId)`; a thread
  list's leases name its thread.
- Fail-before: restoring only unread.ts fails both owner cases (frontier
  31, expected 29) and both InboxPage cases (frontier at the top-level
  message's second, one past the expected cutoff). Restoring only
  use-reading.ts (leases name no thread) fails both InboxPage cases the
  same way. Restoring only ThreadPanel.tsx fails the ThreadPanel case
  (lease `["channel", undefined]`).

Docs: docs/inbox.md no longer says reading a DM, even in one of its
threads, reads all of it. It now says the row's own read does, and
describes the thread cutoff, the conservative unread replies, and the
row opening whole meanwhile. docs/unread.md describes the bounded
thread lease, and docs/buzz-help.md says when a DM row opens a thread
and that DM messages outside it stay unread until the whole DM opens.

Validation (machine load 4–17 throughout; each Vitest file run alone):
unread, unread-startup/-follows/-invalidation/-lookups, inbox-feed,
inbox-reactions, inbox archive/dm-label/index/reaction-rows/route,
notifications messages-reading and messages, ThreadPanel (+identity,
profile, nesting), EmbeddedThread, ConversationTab, useConversationTabs,
ChannelsPage.tabs, use-reading and use-reading.dm all pass; InboxPage
passed 8 of 8 full-file runs after the settle fix (two of them in
parallel, load up to 17). `tsc --noEmit` and `pnpm lint` pass. Chromium
journeys inbox-reading, inbox, inbox-tabs, thread-unread, sidebar-unread
and typing-dm: 41 passed. No load timeouts.

Remaining gap, unchanged here: the row's explicit read on click still
covers the DM through the click time, so a top-level message created by
then but delivered after the click is read without being shown.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signed-off-by: Matt Toohey <[email protected]>

…ing lease

Addresses wesbillman's review thread on PR #2587
(#2587 (comment)),
the unresolved-root gap named in 6f6d25f.

When Activity opens a DM thread at a reply and the thread view cannot
resolve the original ("Original message unavailable"), `ThreadPanel`
named the opened reply (`messageId`) as the reading lease's thread. The
DM thread cut then counted the thread's other replies, which share the
reply's real root, as outside it: they stayed unread while shown. That
failed safe, but left shown replies unread.

The lease's thread is now `snapshot.root?.id ??
snapshot.target?.threadRootId ?? messageId`. `ChannelMessage.threadRootId`
is the canonical root from the reply's signed tags, so an exact reply
names its real thread even without its root. The `messageId` fallback
remains for a view with no root evidence: opened at a root, or an exact
target not yet ready (whose reply the view does not show yet). The
unread subscription keys are unchanged.

Tests: a new ThreadPanel.test.tsx case opens at a reply whose original
is unavailable and asserts every reading lease names the reply's signed
root. It fails before the fix (leases name the reply id) and passes
after. The existing case still covers the fallback when opened at a
root ID.

Docs: docs/unread.md says a thread view opened at a reply whose root it
cannot resolve names that reply's marked root as its thread.
docs/inbox.md and docs/buzz-help.md did not describe the gap and need
no change.

Validation (load average ~4-6; each Vitest file run alone):
ThreadPanel 91/91, ThreadPanel identity 3/3, nesting 34/34, profile
1/1, InboxPage 150/150, use-reading 32/32, use-reading.dm 1/1, unread
162/162. `tsc --noEmit` and `pnpm lint` pass. Not run: browser
journeys, and no manual check in the desktop app.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signed-off-by: Matt Toohey <[email protected]>

* eva/huddle-audio-fixes: (29 commits)
  fix(huddle): keep calls flowing under stalled sends and multiple devices
  fix(channels): wrap unread conversation stepping around the sidebar (#2682)
  fix(navigation): let bare buzz:// open Buzz without a broken-link notice (#2718)
  fix(inbox): open DM thread rows as the thread (#2587)
  test(channels): complete the context navigation fixture (#2783)
  fix(channels): open a thread's channel at its root message from the #channel link (#2377)
  fix(people): find people by a pasted npub or hex key (#2396)
  test(bestie): open the narrow long-history thread with clickRow (#2723)
  Account-first onboarding and sign-in recovery (#2579)
  fix(agents): scroll the avatar dock with a mouse wheel (#2567)
  fix(avatars): keep Done in view when the avatar popup is short (#2706)
  feat(messages): highlight reactions you've made (#2709)
  feat(usage): move Usage from the sidebar into Settings (#2742)
  fix(messages): keep a playing row mounted in the channel timeline (#2695)
  Fix plugin status declaration closure for author consumers (#2643)
  fix(navigation): keep empty new chats out of Back history (#1617)
  [buzz-app] Recover remote agent message outcomes (#2542)
  feat(messages): name background send destinations and attach the files that fit (#2406)
  feat(drafts): clear a draft from its row (#2725)
  Authorize external application identities in Buzz (#2685)
  ...

Co-authored-by: Eva <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
Co-authored-by: Tyler Longwell <[email protected]>
Signed-off-by: Tyler Longwell <[email protected]>

# Conflicts:
#	docs/huddles.md
#	src-tauri/src/relay/huddle/audio.rs

…leanup

* origin/main: (84 commits)
  Restore macOS Cmd-W window closing when no tab handles it (#2443)
  Make agent transcripts quieter and link finished replies to activity (#2424)
  fix(channels): wrap unread conversation stepping around the sidebar (#2682)
  fix(navigation): let bare buzz:// open Buzz without a broken-link notice (#2718)
  fix(inbox): open DM thread rows as the thread (#2587)
  test(channels): complete the context navigation fixture (#2783)
  fix(channels): open a thread's channel at its root message from the #channel link (#2377)
  fix(people): find people by a pasted npub or hex key (#2396)
  test(bestie): open the narrow long-history thread with clickRow (#2723)
  Account-first onboarding and sign-in recovery (#2579)
  fix(agents): scroll the avatar dock with a mouse wheel (#2567)
  fix(avatars): keep Done in view when the avatar popup is short (#2706)
  feat(messages): highlight reactions you've made (#2709)
  feat(usage): move Usage from the sidebar into Settings (#2742)
  fix(messages): keep a playing row mounted in the channel timeline (#2695)
  Fix plugin status declaration closure for author consumers (#2643)
  fix(navigation): keep empty new chats out of Back history (#1617)
  [buzz-app] Recover remote agent message outcomes (#2542)
  feat(messages): name background send destinations and attach the files that fit (#2406)
  feat(drafts): clear a draft from its row (#2725)
  ...

# Conflicts:
#	src/bundled/builderlab/adapter-type/Activity.test.tsx

## Problem

`[webkit] tests/browser/notifications.spec.mjs:274 › a fully visible
incoming row stays quiet without publishing read intent` fails
intermittently at line 366: the live mention's `attention(...).unread`
is `false` (Expected `true`) just before `page.clock.resume()`.

Failing runs:

- [Run 42218773714, job
127896226733](https://github.com/block/buzz-app/actions/runs/42218773714/job/127896226733)
(Browser journeys webkit 9/14, PR 2779, which doesn't touch
notifications or the timeline)
- [Run 42216085209, job
127889153841](https://github.com/block/buzz-app/actions/runs/42216085209/job/127889153841)
(`main` at 3bcf1c4)
- [Run 42152898799, job
127682329346](https://github.com/block/buzz-app/actions/runs/42152898799/job/127682329346)
(`main`)
- [Run 42149589737, job
127672336676](https://github.com/block/buzz-app/actions/runs/42149589737/job/127672336676)
(`main`)

The race is in the product, not the test: a channel's bottom catch-up
could mark read a mention that arrived after its dwell ended.

## Root cause

`catchUp` in `src/features/relay/unread.ts` captures `rows =
byChannel.get(channelId)`, awaits the `activity:<channel>` save, then
filters `rows` for the mentions and broadcast replies to give `msg:`
marks. A live event from another person goes through `extendIndex`,
which pushes onto that same array in place. A mention delivered while
the save is pending, dated no later than the bottom row, was therefore
marked read by a dwell that ended before it existed. The comment above
the code ("check retained evidence at invocation") and `docs/unread.md`
(later attention with an older timestamp stays unread) both say it
should wait for its own dwell.

How the journey hits it, from the failing trace:

1. Focusing the history at 54484 ms starts the 300 ms dwell on the
`Following row`, which is dated now+20 s.
2. `pauseClock(page, 30_000)` runs `fastForward` (54521–54582 ms). That
fires the pending dwell about 40 ms in, and its catch-up starts a
strict-durability IndexedDB save.
3. The test publishes the `Visible mention` at 54590 ms. It is dated
now, so it is older than the bottom row.
4. If the IndexedDB commit outlasts the mention's delivery, the catch-up
then marks the mention read, and line 366 fails. That depends on real
I/O timing, which is why it fails rarely and only on loaded runners.

## Fix

Copy the rows when `catchUp` starts (`[...(byChannel.get(channelId) ??
[])]`). Every decision then uses the evidence retained when the dwell
ended. A row that arrives during the save waits for its own dwell, and
the reader's mutation observer schedules that dwell when the row
renders. `docs/unread.md` now says the `msg:` marks cover rows retained
at dwell completion.

No test timing changed: no timeouts, retries or clock steps.

## Tests

- New unit test in `src/features/relay/unread.test.ts`: "bottom catch-up
leaves older attention that arrives during its save unread". It holds
the catch-up's storage save with the existing `holdSaveStarted` gate,
delivers an older mention, then releases it. Without the fix it fails
with an extra `msg:<late>: 17` frontier. With the fix it passes.
- No browser cases added or removed. The existing journey is the browser
coverage.

## Verification

WebKit, local macOS, Playwright `--project=webkit --no-deps`. "Load"
means 12 `yes` CPU stressors plus 6 processes rewriting a 1 MB file with
`F_FULLFSYNC`.

| Run | Unfixed `main` (3bcf1c4) | This branch |
|---|---|---|
| Journey ×40 under 16 CPU stressors | 40/40 pass (CPU alone didn't
reproduce) | — |
| Journey ×40 under CPU + fsync load | **1/40 fail**, at `:366`,
Expected `true`, Received `false` (same as CI) | 40/40 pass |
| Journey ×30, no load | — | 30/30 pass |
| Local probe (not committed): the spec with the read-state IndexedDB
commit held across the live arrival | **3/3 fail** at the same assertion
(6 read-state saves, the 6th being the leaked `msg:` mark) | 10/10 pass
(5 saves) |
| `notifications.spec.mjs` + `unread.spec.mjs`, Chromium and WebKit | —
| 36/36 pass |

- `vitest run src/features/relay/`: 3157 passed, 4 skipped.
- `unread.test.ts` on a merge of this branch with current `main`
(067db60, #2587, which also edits `unread.ts`): 163/163 pass.
- `biome check --error-on-warnings` on the touched files, `pnpm
typecheck` and `git diff --check`: clean.

Not done: hosted CI on this head, and a human check in the app. Agent
self-review covered the full diff. Other `byChannel` readers were
checked for the same pattern: `channelReadIntent` already computes its
cut and keys up front.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: Matt Toohey <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>

## Problem

Follow a plugin's "Settings: GitHub" link from its details in Manage
plugins, then press Back (⌘[). Manage plugins comes back with no row
expanded and no details pane, so you have to find the plugin again. The
selection was local component state: the Settings visit never recorded
which plugin's details it showed, so Back/Forward had nothing to restore
(#2419 left this open).

## Change

Each Manage plugins visit records the plugin whose details it shows (or
`null`) through the existing per-visit store,
`navigation.savePosition("settings.pluginDetails")`, the same way
`ChannelTimeline` and `ThreadPanel` keep their positions. Back/Forward
to that visit (`navigation.traversal`) reopens those details with focus
on **Close plugin details**. Unchanged: closing details is kept, so
Forward and Back to that visit show the list; choosing Manage plugins
from another section starts at the list; addressed details links
(`pluginId` in the target) behave as before.

Three commits, in landing order:

1. `8a14c4ae1` — record and restore the shown plugin per visit.
2. `2818a4e0d` — adjacent visits: a stored `null` clears a selection
still showing; each new visit records what it starts with; Back from an
addressed visit (for example the plugin-update toast) restores the
earlier visit's details, while Close through `dismissPluginDetails`
still lands on the list; a removed plugin records `null`; "Open in Buzz"
from a plugin import keeps its plugin.
3. `35349385c` — import paths: "Open in Buzz" from a link opened outside
Manage plugins records on the visit that replaced the import; a stale
`onClosed` after Install + Back can't leave the closing flag set; the
effect no longer writes under other sections' entries.

Production change: about 65 lines in `src/app/Settings.tsx`. Docs: one
sentence each in `docs/navigation-history-behavior.md` and
`docs/buzz-help.md`.

## Before and after

Same steps on both builds, Chromium, local fixture data. Left: `main` @
`3bcf1c4bb`. Right: this branch @ `35349385c`. At step 3 (about 0:20),
⌘[ on `main` lands on the list with nothing selected; on the branch
GitHub's details reopen with focus on Close. Steps 5 and 6 show the
unchanged behaviour: Close is kept across Forward/Back, and a sidebar
visit starts at the list.


https://github.com/user-attachments/assets/23493f50-69e7-44a6-89e1-070f337904f9

![Step 3, just after Back. Left: main, no details. Right: this branch,
GitHub's details are
back.](https://github.com/user-attachments/assets/0aad8b57-cd62-41db-943a-3b92416cbf72)

## Tests

- `src/app/Settings.test.tsx`: 11 new cases. **Fail-then-pass:** with
only the test changes on `main`, 6 fail (the Back restore at
`toBeVisible`, both addressed-return cases, and the three import-path
cases); the other 5 guard existing behaviour (inherited details on an
adjacent visit, Close of addressed details landing on the list, Open in
Buzz). All 65 pass on the branch.
- Fixture: one navigation request object per visit (as App's
`route.request`), with `entryId`, `signal`, `position`/`savePosition`,
and `pluginId`/`pluginImport` in the target. A `useSyncExternalStore`
host covers the dismissal that lands synchronously (replace) versus
later (`history.go()`).
- Mutation check: reverting each behavioural change fails at least one
named test. The exception is the redundant flag reset when leaving
Plugins, which is unobservable and kept as belt and braces.
- Suites: `Settings.test.tsx` + `App.profile.test.tsx` (89), App-level
navigation and settings suites, `SettingsSidebar`, `DecisionsSettings`,
`PluginImport`, `src/features/navigation` (19 files, 480). Biome, `tsc
--noEmit`, `git diff --check` clean.
- No browser cases added or removed. The recording above is a harness
flow (fixture relay, Playwright), not a repo journey.

## Review

Two independent agent review rounds. Round 1 found the adjacent-visit
and addressed-visit cases; round 2 reproduced the two import-path cases
and the stray writes. All were fixed with fail-before tests.

## Manual test

1. Settings → Manage plugins → View GitHub details → click **GitHub** in
the "Settings: GitHub" line. Press ⌘[. GitHub's details should be open,
the row expanded, focus on Close plugin details. ⌘] then ⌘[ should do it
again.
2. Close the details. ⌘] then ⌘[: the list, no details.
3. Open any details, click Appearance, then Manage plugins in the
sidebar: the list.
4. With Settings on Manage plugins showing details, trigger a
plugin-update notice and open its details from the toast, then ⌘[: the
earlier details should be back.

## Deferred

- WebKit and the desktop app (WKWebView) weren't re-run on the final
commits; the change is state logic, not layout.
- Branch base is `3bcf1c4bb`; `main` has moved 3 commits (#2587, #2718,
#2682), none touching these files.
- #2621 (draft) uses the changed effect-dependency line as context and
will need a small hand rebase.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: mtoohey <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>

Forward could leave you stuck in two ways. In its To field, the first
Escape closed the people list, and every later Escape did nothing, so
Forward stayed open until you used Cancel or Close. And after More
message actions (⋯) → **Forward message**, closing Forward with Cancel,
Close or Escape left focus on the page body instead of returning it to
⋯.

With this change, the first Escape in To closes the people list and the
next one closes Forward. That retires its visit, as Cancel does. Closing
a Forward opened from ⋯ returns focus to ⋯.

## Before and after

Left: main @ `3bcf1c4bb`. Right: this branch. Same keystrokes on both.
Step 2 (⋯ → Forward → Close): on the left the focus ring is gone because
focus fell to the page body; on the right it's back on ⋯. Step 3: the
toolbar Forward button returns focus on both sides (unchanged). Step 6
(second Escape): on the left nothing happens and the dialog stays open;
on the right it closes and focus is back on ⋯.


https://github.com/user-attachments/assets/cfa6d2ad-a00e-4e52-9adf-2de1ee271b0e

![Second Escape, side by side: on main the Forward dialog stays open; on
this branch it has closed and the focus ring is on
⋯](https://github.com/user-attachments/assets/9d1f93c7-d3b6-430a-a80d-675cb3082335)

| Flow | `main` | This branch |
|---|---|---|
| Forward, To field: Escape with the people list open | Closes the list
| Closes the list (unchanged) |
| Forward, To field: Escape with the list closed | Nothing happens;
Forward stays open | Closes Forward; Back then Forward doesn't bring it
back |
| ⋯ → Forward message → Cancel, Close or Escape | Focus on the page body
| Focus on ⋯ |
| Message context menu → Forward message → Cancel | Focus on the page
body | Focus on the menu's target: the row's first button after a
right-click, or the focused button after Shift+F10 |
| Toolbar Forward button → Cancel | Focus on the Forward button |
Unchanged |
| New message, To field: Escape | Closes an open list | Unchanged |

## The change

The production diff is +22/−8 across two files. `ForwardMessage.tsx` is
unchanged.

**Escape (`RecipientPicker.tsx`).** The To field's wrapper and its input
both handled Escape, and both swallowed it even with the list closed.
Each now acts only while the list is shown: `open && !disabled`, the
same condition as `Popover.Root`'s `open` and the input's
`aria-expanded`. Otherwise Escape reaches the host dialog, which closes
through `close()` → `navigation.dismiss`, as Cancel does. Escape counts
as an explicit close under the [navigation history
contract](https://github.com/block/buzz-app/blob/main/docs/navigation-history.md#passive-navigation-preserves-explicit-close-dismisses),
so the visit is retired. Both gates are needed, because either handler
alone still swallows the second Escape. An Escape during IME composition
still can't close Forward: Base UI's `useDismiss` ignores Escape while
`isComposing`.

**Focus (`MessageActionBar.tsx`).** Forward returns focus to whatever
had focus when it opened. From the ⋯ menu, that was the Forward menu
item, which unmounts with the menu, so focus fell to the page body. The
Forward menu item now focuses the menu's target (with `preventScroll`)
just before it calls `onForward`:
- ⋯, however its menu was opened;
- on the context-menu path, the context menu's own target
(`contextFocus`), if it's still connected.

This mirrors the toolbar Forward button, which focuses itself, and
Report in the same menu, which returns focus to ⋯
(`finalFocus={menuTrigger}` in `MessageRow.tsx`). `MessageActionBar`
keeps its own ref to ⋯ when no `menuTriggerRef` is passed.
`menuTriggerRef` is narrowed to a `RefObject`, which its only caller,
`MessageRow`, already passes.

With no connected return target, `ForwardMessage.tsx`'s `finalFocus`
still returns `false`, so focus goes to the page body rather than to an
unrelated control.

## Why not `finalFocus → true`

The first version made Forward's `finalFocus` return `true`, and review
showed that this can put focus on an unrelated control. `true` hands the
choice to Base UI's fallback list, which every Base UI popup in the app
shares. Each popup adds the element that had focus when it opened, and
Base UI focuses the newest entry still in the page, even if it has
nothing to do with this message. So ⋯ got focus back only if ⋯ itself
had focus when its menu opened. Two real paths miss that:
- **A pointer press on ⋯ in WebKit**, which is the macOS app's webview.
WebKit doesn't focus buttons on click, which is why the toolbar's Reply
and Forward buttons focus themselves.
- **The message context menu.** Right-clicking text focuses no button,
and the hand-off dropped the context menu's own return target.

In both paths, focus after Cancel or Send jumped to an earlier control,
so the next Enter or Space would activate it. In the test, that's a
button called "Elsewhere" from an unrelated menu. Focusing the menu's
target explicitly avoids the fallback list.

## Shift+Escape in New message

The picker's modifier guard doesn't exclude Shift. With the list closed,
Shift+Escape in New message's To field now reaches the app-wide Mark all
as read shortcut, as it does in other fields. Plain Escape there has no
ancestor handler, so New message behaves as before. Inside Forward, Mark
all as read isn't available in a modal visit, so Shift+Escape only
closes the dialog.

## Tests

`src/features/messages/ForwardMessage.test.tsx` adds six tests. All of
them fail on `main` and pass with this change:
- Escape closes the people list, then the dialog, and Back then Forward
doesn't bring the dialog back. On `main`, the dialog stays open after
the second Escape. Reverting either picker gate on its own also fails
this test.
- ⋯ opened from the keyboard → Forward message → Cancel, and → Escape,
Escape (`it.each`): focus returns to ⋯. On `main`, it's on `<body>`.
- A menu on a button called "Elsewhere" is opened and closed. Then ⋯ is
pressed without being focused (`fireEvent` with `detail: 1`, standing in
for the WebKit press), then Forward message → Cancel. Focus must land on
⋯. It's on `<body>` on `main` and on "Elsewhere" with the `finalFocus →
true` version.
- Context menu → Forward message → Cancel, opened by right-click and by
Shift+F10 (`it.each`). Focus returns to the row's first button after a
right-click, and to the button that had focus after Shift+F10.

| Check | Result |
|---|---|
| `ForwardMessage`, `NewMessage`, `NewMessage.recovery` and
`MessageActionBar` tests | 150/150 |
| Those four files plus the `MessageActionBar`/`MessageRow` importers
(`MessageRow`, `ReportMessageDialog`, `ActivityGroupPreview`,
`ThreadPanel`, `ThreadPanel.nesting`) | 470/470 at `85f2e372c` on
`3bcf1c4bb`; 472/472 at this head, `00875cfd0`, where #2587 adds two
`ThreadPanel` tests |
| The five new focus tests, 5 runs in a row | 5/5 on each run |
| `tsc --noEmit` (`tsconfig.json` and `tsconfig.design.json`), `biome
check`, `git diff --check` | Pass on both heads |

No browser journeys were added or removed. The component tests cover the
behaviour, and the browser checks below used scratch specs that aren't
committed.

## Browser checks

Scratch Playwright specs ran against the channel fixture workspace in
Chromium and WebKit (Linux WebKit during review, macOS Playwright WebKit
locally). The recording above uses Chromium.
- **Pointer: ⋯ → Forward message → Cancel.** Focus ends on ⋯ without
`:focus-visible`, and the action bar hides once the pointer leaves, so
#397's action-bar pinning doesn't come back. On `main`, focus lands on
`<body>`.
- **Keyboard close: Escape, Escape, after the menu was opened by pointer
or keyboard.** Forward closes and focus returns to ⋯. Base UI marks a
keyboard close as focus-visible, so after a pointer open the bar stays
shown. That matches #397's own case for a keyboard dismissal of a
pointer-opened menu, and the toolbar Forward button behaves the same
way. On `main`, the second Escape leaves Forward open.
- **A no-focus press on ⋯ (dispatched `pointerdown`/`mousedown`) and the
right-click coordination row.** Focus returns to the menu's target,
while on `main` it lands on `<body>`.
- **Scroll.** The hand-off and Base UI's focus return both use
`preventScroll`, and the scroller didn't move.

No visual design changes: the diff changes only key handling in the
feature-owned `RecipientPicker` and the focus hand-off in
`MessageActionBar`'s existing menu. Because nothing renders differently,
themes, narrow widths and enlarged text weren't re-checked.
`docs/buzz-help.md` doesn't describe Escape or focus return for Forward,
so it needs no change.

## Deferred checks

- **Native macOS app (WKWebView): a pointer press on ⋯ → Forward message
→ Cancel.** That press doesn't focus ⋯, and no automated engine here
reproduces it: Linux WebKit focuses buttons on click, and so did
Playwright's macOS WebKit. The jsdom "Elsewhere" test stands in for it.
- **Bestie conversation fixture.** Forward → Cancel already drops focus
to `<body>` on `main` from every Forward entry point, including the
toolbar button, and it still does on this branch. Its provider records
the return target in one owner, and a different owner renders the
dialog. This isn't a regression, and this PR doesn't claim to fix every
Forward entry point. How the real app mounts Bestie wasn't checked.
- **Not run:** Firefox and screen readers.
- **Human test:** still to do, so this PR stays a draft.

## Agent review

Two agent reviews ran:
- **First review (the `finalFocus → true` version).** It confirmed the
Escape fix, including the one-person limit, no matches, the disabled
state, IME and New message. It flagged the `true` fallback, which led to
the explicit hand-off above.
- **Second review (the reworked version).** It found no blockers:
  - no #397 pinning and no scroll jump;
  - no conflict with `handingOffFocus` or row retirement;
  - the `RefObject` narrowing is safe;
  - the jsdom press is a fair stand-in for the WebKit press.

All three of its suggestions were applied: clearer comment wording, an
`it.each` over right-click and Shift+F10, and one commit with an
accurate message.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: mtoohey <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>

…2803)

## Problem

Close all tabs (right-click a tab, ⌘⇧W, or the macOS **Close All Tabs**
menu item) closes the whole right pane. A launcher's side panel such as
Todos goes with it, even though it isn't a tab.

- Its launcher still reads pressed (`aria-expanded="true"`), so the
first press "closes" the hidden panel and nothing visible happens. Only
the second press brings Todos back.
- **Toggle tab pane** and **Back** to the channel visit end the same
way: Todos is hidden and the launcher reads pressed. Close all tabs from
that earlier channel visit also hides Todos.

## Fix

Close all tabs now leaves a launcher's side panel as it was: shown in an
open pane, hidden in a closed one. The launcher reads pressed only while
the pane shows the panel, so one press always brings it back. Production
change: 23 lines added and 5 removed, in 4 files.

1. **`closeTabs`** (`useChannelTabState.ts`): `paneOpen: side ||
(s.paneOpen && !!s.sidePanel)`. A pane showing a launcher's panel stays
open, and a closed pane stays closed.
2. **`onCloseTabs`** (`ChannelsPage.tsx`): when nothing is kept and a
launcher's side panel is selected, shown or hidden, it dismisses toward
the `"side"` pane, not `"main"`.
- `dismissContent` then records the existing side-panel survivor from
#1767, so the return to the channel visit keeps Todos. That's the same
path that keeps Todos when its last tab closes with X.
- The kept-return marker records the pane's pre-close visibility: a kept
tab shows, and a side panel keeps `paneOpen` as it was. The matching
return applies it after `enterVisit`, so a channel visit that saved an
open pane (a retained thread or Todos was in it) doesn't reveal the
Todos the user had hidden before ⌘⇧W.
3. **Launcher `pressed` and `toggle` via `shown`**
(`useChannelPanels.tsx`): a side panel counts as `shown` only while the
pane is open, and `pressed` and `toggle` use `shown`.
- On a hidden panel, one press goes through `onOpen`
(`setPaneOpen(true)`) and shows the pane with the panel.
- `selected` is unchanged, so the panel stays retained while the pane is
hidden.
- `ChannelPanelTabs` gains `paneOpen`. `useConversationTabs.tsx` passes
`tabState.paneOpen`, the flag its tab-placed `pressed` already reads.

Close other tabs on a main-pane tab now keeps the side panel beside it
too.

**Preserved:**
- [Navigation
history](https://github.com/block/buzz-app/blob/main/docs/navigation-history.md):
closed thread visits are still retired together. Back and Forward still
skip them, and no visit's saved pane state changes. Back to a channel
visit still restores that visit's saved pane. Where it was hidden, Todos
stays hidden, but the launcher now reads unpressed and one press shows
it.
- No visual change. Pressed now matches what's on screen.

**Docs:**
- `shell-design.md` describes Close all tabs and hiding the pane for
side panels.
- `plugin-architecture.md` defines `pressed` for `channelPlacement:
"side"` as "shown in the open pane", not merely selected.

## Tests

**Vitest** (`useConversationTabs.test.tsx`; `launcherHarness` gains a
`placement` parameter):
- "Close all tabs leaves a launcher's side panel as the open/closed pane
showed it":
  - The open case fails on main.
- The closed case fails if `closeTabs` drops the `s.paneOpen &&` guard.
- "a side panel's launcher reads unpressed while the closed pane hides
it, and one press shows it": catches the launcher change.
- "Close other tabs on a main-pane tab keeps a launcher's side panel
open beside it."

**Journey** (`tests/browser/todos.spec.mjs`): "Todos isn't a tab: Close
all tabs keeps it, and its launcher tracks the pane". This is one new
browser case; none were removed.
- **Why it needs a browser:** Close all tabs retires the thread's
history visit, and the page's return to the channel visit has to keep
the side panel. jsdom page tests don't route visits through navigation.
- **What it covers:**
1. Toggle tab pane hides Todos with the launcher unpressed, and one
press shows it.
  2. Close all tabs from a thread visit keeps Todos.
3. Back to a channel visit that saved a closed pane hides Todos, one
press shows it, and Close all tabs from there keeps it. Since #2838 a
channel visit showing Todos saves an open pane, so the journey hides the
pane there first.
4. ⌘⇧W from a thread visit with the pane closed doesn't reveal Todos,
even when the channel visit it returns to saved an open pane.
- **What fails without each part:**
  - On main, it fails at the first launcher check after Toggle tab pane.
- With the `closeTabs` change reverted, it fails at Close all tabs from
the channel visit.
  - With only the launcher change, Todos is gone after Close all tabs.
- If the return drops the kept-return marker's `paneOpen`, it fails at
the ⌘⇧W step from a closed pane.

**Fail before, pass after:**
- With only the first commit's tests applied to main, Vitest fails 2 of
42. The journey fails in Chromium and WebKit, where `aria-expanded` is
"true" after Toggle tab pane.
- With the fix:
- 139 Vitest tests pass across `useConversationTabs`,
`useConversationTabs.panels`, `useChannelPanels`, `useChannelTabState`
and `ChannelsPage.tabs`.
- `todos.spec.mjs`, `tab-close-others.spec.mjs` and
`right-pane-dismissal.spec.mjs` pass in Chromium and WebKit, 32 tests in
all. So does the layout.spec case "Todos stacks beside threads".
  - `tsc --noEmit` and `biome check --error-on-warnings` are clean.
- These local runs were on the same three patches before the rebase onto
067db60. That rebase brought in only #2587 (inbox, thread and unread
files), which touches none of this PR's files. The later rebase onto
be67480 brought in #2838 (retained side panels); the journey's Back
setups were reconciled with it in 2a30ea9 and have not been run
locally since.

## Not checked

- The native ⌘⇧W menu. The browser runs dispatch `buzz:close-all-tabs`,
the window event the native menu sends. The page handled it
(`preventDefault`), and the result matched the right-click menu.
- The desktop app.

## Related

- **#2415** reworks the same dismissal-return code. This change depends
on `dismissContent` keeping `(pane === "side" && tabState.sidePanel)`.
Whichever of the two lands second must keep that condition.
- **#1793** (draft, conflicting) rewrites `closeTabs` and changes
`onCloseTabs`. If it's revived, it needs the same two rules:
  - A pane showing a launcher's side panel stays open on Close all tabs.
- `onCloseTabs` dismisses toward the side pane while a launcher's side
panel is selected, and the return reapplies the pane's pre-close
visibility.

## Before and after

Both runs used the same scripted steps on the same timeline. Each run
checked the expected state at every step, and both passed.

| Step (starts at) | Before: main @ 3bcf1c4 | After: this branch @
2c81a4905 |
|---|---|---|
| 1. Press **Toggle channel todos**, then open the thread from its reply
chip (3.6 s) | Thread tab above Todos. Launcher pressed. | Same. |
| 2. Right-click the thread tab, choose **Close all tabs**, hold about
3.5 s (10.0 s) | The whole pane closes, and Todos goes with it. The
launcher still reads pressed, so the badge turns red. | The tab closes.
Todos stays and fills the pane. Launcher pressed. |
| 3. Open the thread again, then ⌘⇧W (16.2 s) | Reopening brings back
the thread with Todos, because Todos was never deselected. ⌘⇧W then
hides both, and the launcher still reads pressed. | ⌘⇧W closes the tab
and Todos stays. Launcher pressed. |
| 4. Open the thread again, then **Toggle tab pane** (23.2 s) | Pane and
Todos hidden. Launcher **still pressed**. | Pane and Todos hidden.
Launcher **not pressed**. |
| 5. Press the Todos launcher once (30.0 s) | Nothing visible happens.
The launcher flips to not pressed and Todos stays hidden. | The pane
comes back with the thread tab above Todos. Launcher pressed. |

2c81a4905 has the same fix and tests as this PR, from before the rebase.
The only later commit changes a comment and docs. The video was recorded
in Chromium against the fixture relay, with ⌘⇧W sent as the
`buzz:close-all-tabs` event. Back, and Close all tabs from the earlier
channel visit, are covered by the journey but not shown in the video.


https://github.com/user-attachments/assets/c40bd79d-7668-4511-b065-915e533ea6e6

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: mtoohey <[email protected]>
Signed-off-by: Matt Toohey <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>