Web sidebar on touch: a small overflow button for thread row actions

[saphid]

Problem. In the web and desktop sidebar, a thread row's actions (Settle, Un-settle, Wake, Snooze) appear only on hover or keyboard focus. Until then they are opacity-0 pointer-events-none (Sidebar.tsx#L1705, #L1890). On a touch or pen device a tap opens the thread, so a touch user can't settle, snooze, wake or pin a thread from the list itself.

What already works. After opening a thread, the chat header title menu and More header actions (ChatHeader.tsx#L460, #L509) offer Pin, Settle, Snooze and Wake. They come from the same buildThreadActionMenuItems as the row's right-click menu (threadActionMenu.logic.ts#L69). So every action is reachable on touch, one thread at a time and only after navigating to it. Hover users, and the native mobile app with its row swipe actions, can triage the list in place. A long-press reaches the row menu only in browsers that fire contextmenu for touch (Sidebar.tsx#L1626). I haven't tested which browsers do.

Proposed narrow outcome. On coarse pointers only (pointer-coarse:), each sidebar row gets one small "More actions" button. It opens the existing row action menu, anchored to the button.

• No gesture, no new actions or menu items, and no change for mouse or keyboard users.
• No contract, server, React Native or SwiftUI changes.
• The cost is about 24px of row width on touch devices, next to the status slot.
• A touch press on the button must not start a row drag.
• It would build on fix(web): screen readers can reach sidebar row actions #13962, which restructures the same row actions for Sidebar thread row actions are unreachable with screen readers #13959.

Background. #11668 built a full swipe workflow: reveal, full-swipe commit, and Pin on a right swipe. It was closed for missing prior approval and missing current media. The closure noted that the touch-access need is worth preserving. This proposal deliberately drops that gesture machinery.

Precedent, not approval. #11020 and #12370 made existing hover-only controls visible on touch with pointer-coarse:. This proposal reuses that pattern, but those PRs don't approve it, because it adds a new control rather than revealing an existing one.

Acceptance criteria, if approved

• With a coarse pointer, Pin/Unpin, Settle/Un-settle, Snooze (presets and Custom…) and Wake are reachable from a sidebar row without opening the thread. They go through the existing menu with its existing gating, confirmations and Undo.
• A tap on the row still opens the thread, and the list still scrolls. Pressing the button never starts a reorder or a drag to another section.
• Fine-pointer rendering and behavior are unchanged.
• The button has an accessible name and a visible focus ring.

Evidence the PR would include

• Focused tests.
• Before/after screenshots on a touch client, from the candidate commit.
• A short continuous recording in a real browser showing tap navigation, overflow → menu → Settle → Undo, and scrolling.
• The environment used and anything not checked.

Decision requested

1. Is a touch-only row overflow button the right direction? Or would you rather make no change, or only make the header menu easier to discover?
2. If it is: should both card and slim rows get it, is LegacySidebar out of scope, and should this wait for fix(web): screen readers can reach sidebar row actions #13962?

If the header menu is the intended touch path, I'm happy to drop this.

[saphid]

I reproduced this on current main (a1d9d72) in a touch-only client and prepared the smallest version of option A on a branch. It's ready if you want it; I haven't opened a PR.

Reproduction. iOS 26.5 Simulator Mobile Safari on an iPad Pro 11-inch, touch only, against an isolated dev server.

• A tap where Snooze or Settle would appear opens the thread instead (before-2). The same happens on a settled slim row (before-4).
• A long-press opens no menu, because iOS doesn't fire contextmenu for a touch (before-3).
• Once a thread is open, the header menu still offers every action (before-5). So this is an in-list gap, not a lost capability.
• Recording.

#15536 fixed iPads with a trackpad by moving these reveals to any-hover. Touch-only devices are unchanged by that fix.

Ready branch: saphid:agent/web-touch-row-menu, commit 705fc60, +33 lines in Sidebar.tsx.

• Under @media (any-hover: none) only, each card and slim row shows one ghost icon-xs "Thread actions" button. It opens the existing row menu, the same one as right-click.
• Pressing the button doesn't start a row drag or open the thread.
• There are no new menu items, gestures, contract changes or mobile changes. Mouse and trackpad users never see it.

After screenshots (same client):

• rows
• menu from the button
• Settle from the menu
• Un-settle from a slim row
• a plain row tap still opens the thread
• recording

Checks. Typecheck, format and scoped lint (0 errors) pass. A GPT-6.1 Sol review approved it with one nit (aria-haspopup), which is applied. Moving keyboard focus into the menu is a separate issue; #15806 covers it.

Not verified:

• a physical iPad or phone, and Android
• desktop hover after the change (the hover code is unchanged)
• scrolling a long list

The decision is still yours. Is a touch-only row button the right direction, or should the header menu remain the touch path? If you approve, I'll open it as one focused PR that links this thread.