Chat visually disappears (scrollTop resets to 0 after tab switch) #35377

Description

scrollTop resets to 0 after first assistant output following tab switch (chat visually disappears).

Reproduction rate: 5/5 on macOS. Confirmed on Windows 11. Bug does NOT reproduce when file changes panel stays closed (no width change).

Root cause: the bug is triggered by a width change of the chat area after a tab switch. The virtual scroll list does not recalculate element positions when the file changes panel is toggled → scrollTop gets corrupted. Method 2 proves the bug is purely a resize issue, not tied to assistant streaming.

Expected behavior: scroll position is preserved across tab switches and file changes panel toggles.

Actual behavior: scrollTop resets to 0. Visual manifestation depends on chat length:

• Long chat (30k+ px): chat area appears empty — early messages evicted from DOM by virtual scroll, latest messages rendered at positions far below viewport
• Medium chat: "beginning of chat with a hole at the top" — some early messages evicted from DOM, remaining messages visible but not at position 0
• Short chat (> viewport, no eviction): scroll jumps to the top — first messages still in DOM, visible

DevTools evidence (macOS):

• scrollTop at time of bug: 0 (confirmed 3x)
• scrollHeight: 46998px, clientHeight: 865px — plenty of room to scroll
• maxScroll: 46133px — scroll is explicitly reset, not a "not enough room" issue
• Console: empty, no JS exceptions
• DOM: messages present and correctly positioned (position: absolute; top: 27k–53k px)

What does NOT trigger:

• Second and subsequent messages (without tab switch) — always fine
• Reload Webview — works correctly
• File changes panel closed throughout (no width change)
• Manual scroll before sending, multi-line input — do not prevent

What fixes:

• Shift+Enter in the input field (triggers reflow)
• OpenCode → Reload Webview / View → Reload
• Keeping file changes panel closed prevents the bug entirely

Hypothesis: the virtual scroll list caches element heights/positions at mount time but does not invalidate them on container resize (file changes panel toggle). The stale measurements cause scrollTo to target a wrong position, resetting scrollTop to 0. Reload Webview starts with a clean cache. Cross-platform reproduction rules out browser engine as root cause.

Workaround: keep file changes panel closed, or Shift+Enter / Reload Webview after the bug.

Plugins

No plugins installed (neither project nor global).

OpenCode version

Desktop 1.17.13

Steps to reproduce

Method 1 (file changes panel open, requires assistant output):

1. Ensure file changes panel is open (right sidebar)
2. Switch to any session tab
3. Send a message to the assistant
4. After streaming completes → scrollTop = 0, chat visually disappears

Method 2 (file changes panel toggle, no message needed):

1. Close file changes panel (chat widens)
2. Switch to any session tab
3. Open file changes panel (chat narrows)
   → Chat disappears immediately. No message required. Also works in fullscreen mode.

Screenshot and/or share link

Operating System

macOS 14.7.4 (Sonoma), Windows 11 Pro 25H2 (26200.8655)

Terminal

N/A (Desktop app)