Summary
On mobile browsers, Intuitive swipe navigation does not respond in Conversation chats even though the same horizontal gesture works in Roleplay chats. The Conversation transcript is not connected to the touch gesture recognizer's expected scroll surface.
Expected behavior
With Intuitive swipe navigation enabled, horizontally swiping over either a Conversation or Roleplay transcript should move backward or forward through the latest assistant message's saved swipes. If Reroll past the newest swipe is disabled, swiping past the newest saved swipe should do nothing.
Actual behavior
Roleplay transcript gestures work, but Conversation transcript gestures are discarded at touchstart, so no swipe navigation occurs.
Steps to reproduce
- Open a Conversation chat on a mobile browser and ensure the latest assistant message has at least two saved swipes.
- Enable Intuitive swipe navigation in Settings.
- Horizontally swipe over non-interactive message content in the Conversation transcript.
- Observe that the active swipe does not change.
- Repeat in a Roleplay chat and observe that the gesture works.
Environment
- Marinara Engine version: Not provided by the reporter; confirmed in current
staging source at 612d4d2ed174ff8ee65b429fdf64004066c0a1b1
- Install type: Not provided
- OS + version: Not provided
- Browser or app shell: Mobile browser; exact browser/version not provided
Logs, screenshots, or video
No logs, screenshots, or video were provided. The defect was confirmed by tracing the current source.
Additional context
ChatArea owns the window-level touch listeners. At packages/client/src/components/chat/ChatArea.tsx:2265-2314, touchstart is accepted only when the event target is inside ChatArea's scrollRef.
Roleplay receives and attaches that ref (ChatArea.tsx:3082; ChatRoleplaySurface.tsx:2113-2127). Conversation instead creates and attaches a private ref inside ConversationView (ConversationView.tsx:530, 1175-1179), and ChatArea never receives it. In Conversation mode, the ref consulted by the touch handler is therefore null, causing every gesture to exit at the !surface guard before distance or direction is evaluated.
The mode gate and navigation mutation already support both Conversation and Roleplay (ChatArea.tsx:2150-2187), so this is a touch-surface wiring defect rather than missing Conversation swipe support. Desktop arrow-key navigation does not consult the scroll ref.
A low-risk repair is to reuse the existing data-chat-scroll contract: mark Conversation's transcript scroller with data-chat-scroll, then resolve the nearest marked scroller from the touch target instead of consulting the Roleplay-only ref. Passing the raw Roleplay scroll ref into Conversation is riskier because ChatArea also drives Roleplay scroll/stream/load-more effects that Conversation already implements locally.
Focused mobile regression coverage should exercise both Conversation and Roleplay with a seeded two-swipe assistant message, while preserving vertical scrolling and ignoring gestures that begin on controls/editable fields. Existing targeted coverage only exercises desktop keyboard navigation in Roleplay (e2e/core-flows.e2e.ts:3981-4034).
Template check
Please uncheck (untick) the box below before submitting so we know you read the template. It is intentionally pre-checked:
Summary
On mobile browsers, Intuitive swipe navigation does not respond in Conversation chats even though the same horizontal gesture works in Roleplay chats. The Conversation transcript is not connected to the touch gesture recognizer's expected scroll surface.
Expected behavior
With Intuitive swipe navigation enabled, horizontally swiping over either a Conversation or Roleplay transcript should move backward or forward through the latest assistant message's saved swipes. If Reroll past the newest swipe is disabled, swiping past the newest saved swipe should do nothing.
Actual behavior
Roleplay transcript gestures work, but Conversation transcript gestures are discarded at
touchstart, so no swipe navigation occurs.Steps to reproduce
Environment
stagingsource at612d4d2ed174ff8ee65b429fdf64004066c0a1b1Logs, screenshots, or video
No logs, screenshots, or video were provided. The defect was confirmed by tracing the current source.
Additional context
ChatAreaowns the window-level touch listeners. Atpackages/client/src/components/chat/ChatArea.tsx:2265-2314,touchstartis accepted only when the event target is insideChatArea'sscrollRef.Roleplay receives and attaches that ref (
ChatArea.tsx:3082;ChatRoleplaySurface.tsx:2113-2127). Conversation instead creates and attaches a private ref insideConversationView(ConversationView.tsx:530,1175-1179), andChatAreanever receives it. In Conversation mode, the ref consulted by the touch handler is therefore null, causing every gesture to exit at the!surfaceguard before distance or direction is evaluated.The mode gate and navigation mutation already support both Conversation and Roleplay (
ChatArea.tsx:2150-2187), so this is a touch-surface wiring defect rather than missing Conversation swipe support. Desktop arrow-key navigation does not consult the scroll ref.A low-risk repair is to reuse the existing
data-chat-scrollcontract: mark Conversation's transcript scroller withdata-chat-scroll, then resolve the nearest marked scroller from the touch target instead of consulting the Roleplay-only ref. Passing the raw Roleplay scroll ref into Conversation is riskier becauseChatAreaalso drives Roleplay scroll/stream/load-more effects that Conversation already implements locally.Focused mobile regression coverage should exercise both Conversation and Roleplay with a seeded two-swipe assistant message, while preserving vertical scrolling and ignoring gestures that begin on controls/editable fields. Existing targeted coverage only exercises desktop keyboard navigation in Roleplay (
e2e/core-flows.e2e.ts:3981-4034).Template check
Please uncheck (untick) the box below before submitting so we know you read the template. It is intentionally pre-checked: