Touch message actions unreachable on hybrid hover+touch devices (kebab gated on @media hover:none)

[sanity]

Context

Follow-up from #402 / PR #403 (touch-friendly message actions). The kebab (⋮) message-action menu, and the touch-only pointer-events:none on the hover action bar, are gated on @media (hover: none) (see ui/assets/main.css .touch-actions / .hover-actions).

@media (hover: none) is the exact complement of Tailwind's automatic @media (hover: hover) wrapping on group-hover: utilities, and it correctly covers the issue's targets — phones, tablets, iPadOS Safari (all report hover: none).

The gap

Genuinely-hybrid devices that report hover: hover but are being driven by touch — Windows 2-in-1s in tablet mode, touchscreen Chromebooks, Android/tablet with a mouse attached, Samsung DeX. On those:

• the kebab is display:none (because hover: none doesn't match), AND
• the hover action bar needs a real hover a finger can't produce,

so a touch-only user has no path to reply / edit / delete / react.

Most such devices do have a pointing device (that's why they report hover: hover), so it's a real-but-minority stuck case, not a phone regression.

Options (needs a decision)

1. Keep @media (hover: none) (current) — cleanest; hybrid touch-only users are unserved. Accept as a v1 tradeoff.
2. @media (hover: none), (any-pointer: coarse) for the .touch-actions display — shows the kebab on anything with a touch capability. Downside: hybrid laptops (mostly mouse-driven) get always-visible kebabs on every message (clutter), and it re-opens the tap-interception question on the hover bar (whose pointer-events:none would then need the same widening, which breaks mouse use of the bar on those devices).
3. JS pointer-type detection (pointerdown pointerType) to switch affordance per actual input — the only fully-correct fix, but more machinery than a media query.

No overlapping issue exists (checked open issues for hover/touch/pointer/kebab/any-pointer). Not urgent — the primary targets from #402 work.

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-07-24T12:44:23.008232562+00:00
Issue hash: 12d12017

Value Assessment

The code matches the issue description exactly — .touch-actions and .hover-actions are still gated purely on @media (hover: none) in ui/assets/main.css, unchanged since #402 merged. No any-pointer handling or JS pointer-type detection has been added. The issue is fully relevant and unresolved.

Relevance: Confirmed current — the CSS at lines 128-145 is exactly as described, with the same comment referencing #402. Nothing since has touched this gap.

User impact: Low-to-moderate. The affected population is a genuine minority — Windows 2-in-1s in tablet mode, touchscreen Chromebooks, Android tablets with an attached mouse, Samsung DeX — devices that report hover: hover but are actually being driven by touch at a given moment. For these users the impact is total within that mode: no path at all to reply/edit/delete/react on messages, not just an inconvenience. But it's a narrow, session-dependent slice of River's user base, likely small relative to phone/tablet-only users already served by #402.

Strategic alignment: Moderate. River's core goals are decentralized messaging correctness and security; this is a UI polish/accessibility gap, not blocking any protocol or contract work. It matters for inclusivity and multi-device usability but isn't core-roadmap-critical.

Blocking factor: None — it doesn't block other work; it's an isolated CSS/UX follow-up.

Urgency: Low. The issue itself says "not urgent — the primary targets from #402 work," and it explicitly needs a design decision among three tradeoffs before implementation, meaning it's not shovel-ready. Reasonable to leave open as a backlog/good-first-issue candidate rather than prioritize now.

Cost Assessment

Now I have enough to assess this.

The code the issue references still matches current state exactly: ui/assets/main.css lines ~115-146 still gate .touch-actions display and .hover-actions pointer-events purely on @media (hover: none), and conversation.rs still wires the kebab button through .touch-actions for the touch-only affordance from #402/#403. Nothing has drifted — this is a live, accurately-described gap, not stale.

Scope/complexity depend entirely on which option is chosen, and the issue itself flags that as an open decision, which is really the bulk of the cost here. Option 1 (do nothing, document as accepted tradeoff) is near-zero cost — just closing the issue with a decision. Option 2 (widen the media query to (hover: none), (any-pointer: coarse)) is a small, mechanical CSS change (touches ~2 rules in main.css), but it's not free: the issue's own analysis shows it reintroduces clutter on hybrid mouse-first laptops and reopens the .hover-actions pointer-events: none tap-interception problem that PR #403 specifically fixed for pure-touch devices — so "widen the query" likely needs accompanying logic changes (e.g., only disabling pointer-events on the hover bar where the kebab is also shown, or accepting the UX regression). Option 3 (JS pointer-type detection via pointerdown/pointerType) is real feature work: it needs new Dioxus state to track "last input was touch" per session (or per message), event listeners wired into the message row, and careful interaction with the existing TOUCH_ACTION_MENU_OPEN-style signal already in conversation.rs (~line 1036) — a moderate, self-contained frontend change, roughly a day of work including the state plumbing and defer()-safety (per this repo's Dioxus WASM signal-safety rules, any new signal mutation from a pointer event handler must go through crate::util::defer()).

External dependencies: none — no services, keys, or approvals, purely a frontend CSS/Rust change. Risk: low-to-moderate for options 2/3 since they touch a recently-shipped, carefully-tuned touch-affordance area (#402/#403) with documented edge cases (z-index stacking of kebabs, pointer-events interception, tap-to-scroll on reply strips) — a careless widening could regress the already-solid phone/tablet UX that #403 fixed. Testing effort is nontrivial for correctness confidence: there's no real hybrid-hardware CI, so verification is manual (Playwright can spoof hover/pointer media features via page.emulateMedia(), which is a reasonable low-cost test for option 2, but option 3's real pointerType detection can't be meaningfully emulated in Playwright's default mouse-only mocks and would need manual testing on an actual 2-in-1/touchscreen device or trust in unit-level logic tests for the state machine alone).

Overall: cheap to close as "accepted v1 tradeoff" (Option 1), small-medium (~half day + manual verification) for the CSS widen (Option 2), or medium (~1 day) for proper pointer-type detection (Option 3) — but the primary cost driver is that a product decision must be made first; the coding itself is modest either way.

---

Generated by issue-prioritizer