[Bug]: Chat loses scroll position when switching tabs inside an inline HTML render #17463

Activity

1. kr4chinin

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 9, 2026
2. juliusmarminge commented on Oct 9, 2026

   

   juliusmarminge

   on Oct 9, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Report: on macOS desktop, switching tabs inside an interactive inline html_render (sections of different heights) makes the chat jump vertically and lose the reading position. Reporter has a recording; not reproduced by them in a dev build. App version not given.

   Plausible path on main: a tab change that alters page height reports up to the host, the inline frame resizes, and the virtualized timeline either re-pins to the end (if live-follow is still on) or shifts without browser scroll anchoring.

   1. Height report → frame resize

      • Injected bootstrap watches the framed document with ResizeObserver and posts ui/notifications/size-changed with the new content height (bootstrap).
      • HtmlRenderDocument listens for that message and calls onContentHeight.
      • HtmlRenderFrame feeds that into htmlRenderFrameHeight and sets the outer box style={{ height }} (L95, L102).

   2. Timeline reaction

      • While liveFollowEnabled is on, LegendList maintainScrollAtEnd is active with itemLayout: true (config), so a row height change can re-pin to the end. ChatView documents that this re-pin is independent of the scroll-mode refs (~L6350).
      • The scroll node sets [overflow-anchor:none] (L1620). With live-follow off, LegendList maintainVisibleContentPosition has size: true (L1125-L1131); whether that fully keeps a mid-render reading position when the iframe itself grows or shrinks is unverified here.

   3. Clicks inside the iframe and live-follow opt-out

      • Opt-out attaches wheel / touchmove / pointerdown on the timeline scroll node and keydown on document (ChatView ~L6547-L6656).
      • The inline frame is sandboxed (allow-scripts allow-forms only) (BrowserDocumentFrame L128). Focus and pointer events inside that document do not bubble to the parent, so a tab click in the render looks unlikely to hit handlePointerDown / handleWheel.
      • If the reader reached the render without an opt-out the parent saw (same class of gap as #17056), live-follow can remain on; the next height report then re-pins. That is a plausible cause for the jumps in the recording, not a measured reproduction.

   Open PR #17065 (fixes #17056): adds a timeline scroll listener plus createUpwardScrollDetector so an upward scroll that chained out of the iframe (with no parent wheel/pointer event) turns live-follow off. That targets wheel/trackpad scrolling over the frame. A tab click that only changes height inside the iframe and does not move the timeline scroll offset would not fire that detector, so #17065 alone looks unlikely to cover this interaction.

   Related (not treating as duplicate):

   • #17056 — scroll over the iframe fails to stop live-follow; snap on later layout change. Same height/live-follow machinery; different gesture (wheel vs in-frame tab UI).
   • #16977 — wheel stuck at the edge of a tall capped render (scroll chaining), not tab-driven height changes.

   Ask: app version (or nightly build id) for the recording, and whether the jump lands at the bottom of the thread or only shifts the render in place. That would help tell live-follow re-pin apart from a free-scroll size shift.
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 9, 2026
4. kr4chinin commented on Oct 9, 2026

   

   kr4chinin

   on Oct 9, 2026

   Author

   More actions

   Thanks — here are the requested details.

   App version / nightly build: 0.0.46-nightly.20261009.2861, T3 Code (Nightly) desktop on macOS 26.6.2 (25G83).

   I checked the installed app bundle (CFBundleShortVersionString and CFBundleVersion). The current desktop process started at 15:07 on October 9, before the recording at 17:41, and the installed application files were last modified earlier that morning. This ties the version to the session used for the recording, rather than just quoting an unrelated current nightly.

   Where the jump lands: visually, it appears to re-anchor to the bottom of the thread, rather than only shifting a render while keeping the same reading position. The HTML render is in the final assistant reply. After tab changes settle, the end of that reply remains just above the composer, while the render heading and tab controls move up/down substantially as the selected section changes height. Switching to the taller sections can move the heading/tab controls out of view; switching back to a shorter section brings earlier content back into view.

   This is based on reviewing the existing 8-second recording, not an instrumented reproduction: I cannot give a measured scrollTop, distance from the end, or liveFollowEnabled value from the video. The visible behavior is consistent with an end re-pin, but I have not confirmed the internal cause or tested #17065.

   The recording is already attached in the issue: https://github.com/user-attachments/assets/7ed10e12-aece-4d14-beab-7150fc640086