Describe the bug
When viewing a longer chat thread (for example the public channel), the view jumps/scrolls to the bottom whenever the sync state changes. This makes it difficult to read older messages because the user's scroll position is repeatedly lost while sync activity starts/stops.
To Reproduce
Steps to reproduce the behavior:
- Open a chat/thread with enough history to scroll, especially a public channel/thread.
- Scroll upward to read older messages so the bottom/latest message is no longer visible.
- Wait for the device/app sync state to change, e.g. syncing starts/stops or the sync/status pill changes state. For me it happens if my companion node is a couple rooms away for instance, and bluetooth is intermittently disconnecting.
- Observe that the chat view jumps back down to the bottom/latest message.
- Repeat while continuing to read; each sync-state change can pull the user away from their current reading position.
Expected behavior
Changing sync/status state should not force-scroll the active chat/thread. If the user is not already at the bottom and is actively reading older messages, the app should preserve their current scroll position. Auto-scroll-to-bottom should only happen for intentional cases such as opening a conversation, sending a message, tapping a “jump to latest” affordance, or when the user is already at/near the bottom.
Actual behavior
The chat/thread appears to scroll to the bottom whenever sync state changes. This is especially disruptive in public or longer threads where the user is trying to browse history.
Screenshots
No screenshot attached; this is a scroll-position behavior.
Device (please complete the following information):
- Device: iPhone 16 Pro
- OS: iOS 26.5.2
- Version: Production build from App Store
Additional context
In case it's helpful, my AI agent produced the following looking at the codebase:
This feels related to sync/status UI changes triggering a chat view re-render, snapshot apply, or scroll-to-bottom request. Possible areas to inspect from the current codebase:
MC1/ContentView.swift uses .syncingPillOverlay(...) on the main tab view.MC1/State/AppState.swift computes statusPillState from connectionUI.syncActivityCount / .syncing.MC1/State/ConnectionUIState.swift wires sync activity callbacks.- Chat scroll state lives around:
MC1/Views/Chats/ChatConversationView.swiftMC1/Views/Chats/ChatConversationMessagesContent.swiftMC1/Views/Chats/Components/ChatMessagesTableView.swiftMC1/Views/Chats/Components/ScrollState/ChatScrollState.swift
A good fix would preserve scroll position across sync/status-only state changes and avoid treating those changes as equivalent to new-message/send/open-conversation events.
Describe the bug
When viewing a longer chat thread (for example the public channel), the view jumps/scrolls to the bottom whenever the sync state changes. This makes it difficult to read older messages because the user's scroll position is repeatedly lost while sync activity starts/stops.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Changing sync/status state should not force-scroll the active chat/thread. If the user is not already at the bottom and is actively reading older messages, the app should preserve their current scroll position. Auto-scroll-to-bottom should only happen for intentional cases such as opening a conversation, sending a message, tapping a “jump to latest” affordance, or when the user is already at/near the bottom.
Actual behavior
The chat/thread appears to scroll to the bottom whenever sync state changes. This is especially disruptive in public or longer threads where the user is trying to browse history.
Screenshots
No screenshot attached; this is a scroll-position behavior.
Device (please complete the following information):
Additional context
In case it's helpful, my AI agent produced the following looking at the codebase:
This feels related to sync/status UI changes triggering a chat view re-render, snapshot apply, or scroll-to-bottom request. Possible areas to inspect from the current codebase:
MC1/ContentView.swiftuses.syncingPillOverlay(...)on the main tab view.MC1/State/AppState.swiftcomputesstatusPillStatefromconnectionUI.syncActivityCount/.syncing.MC1/State/ConnectionUIState.swiftwires sync activity callbacks.MC1/Views/Chats/ChatConversationView.swiftMC1/Views/Chats/ChatConversationMessagesContent.swiftMC1/Views/Chats/Components/ChatMessagesTableView.swiftMC1/Views/Chats/Components/ScrollState/ChatScrollState.swiftA good fix would preserve scroll position across sync/status-only state changes and avoid treating those changes as equivalent to new-message/send/open-conversation events.