Spaces:
Running
Running
| /* ── Long-conversation rendering optimizations ───────────────────────── | |
| * | |
| * Three CSS optimizations have been tried on ``.message-row`` and all | |
| * three were ULTIMATELY REMOVED because each caused a real, repeatable | |
| * scroll-geometry bug: | |
| * | |
| * 1. ``contain: layout`` — when a child ``<details | |
| * class="thinking-block">`` collapsed (either via | |
| * ``markThinkingDone`` mid-stream OR via a user click), the row's | |
| * contribution to ``#hy-chat``'s ``scrollHeight`` got stranded at | |
| * the pre-collapse value on Chromium. The user would scroll up | |
| * to read history, drag the scrollbar back to the bottom, and | |
| * the thumb would hit the end of the track while the chat | |
| * stopped many screens above the latest message; the wheel did | |
| * nothing because they really were at ``scrollHeight - | |
| * clientHeight``. Manually toggling the collapsed Thinking block | |
| * open forced a relayout that fixed it — the diagnostic | |
| * fingerprint. | |
| * | |
| * 2. ``contain: paint`` — the same symptom recurred under a | |
| * narrower trigger: assistant turns containing wide elements | |
| * (most commonly markdown tables, also ``katex-display`` blocks, | |
| * and fenced code with long lines). ``paint`` containment makes | |
| * the row a stacking context AND clips overflow at the contain | |
| * box. Combined with the post-stream lazy-render passes | |
| * (``hljs.highlightElement``, KaTeX re-render of the streaming | |
| * tail, table column-width pass), the row's reported size in | |
| * ``#hy-chat``'s scroll metrics drifted away from its real | |
| * rendered size by hundreds-to-thousands of pixels. Toggling | |
| * Thinking no longer fixed this case because the stranded value | |
| * was on the post-table row, not the row containing Thinking. | |
| * | |
| * 3. ``content-visibility: auto`` — skipping render for off-screen | |
| * rows. Row heights vary wildly (a "你好" reply is ~40px, a | |
| * math derivation or table-heavy answer is 3000–5000px). With | |
| * ``contain-intrinsic-size: auto 240px`` as the placeholder, | |
| * scrolling up by a tiny amount caused off-screen rows to expand | |
| * from 240px to their real size, growing ``scrollHeight`` by | |
| * thousands of pixels in a single frame. Browser scroll | |
| * anchoring did not reliably compensate, so the view jumped far | |
| * up the conversation and felt broken. | |
| * | |
| * If we ever need any of these optimizations back, gate them behind a | |
| * row-count threshold (only apply to rows older than the last N) and, | |
| * for option 3, measure each row's real height before swapping it out | |
| * so ``contain-intrinsic-size`` is per-row rather than a single | |
| * global guess. For options 1 & 2, also wire a ``ResizeObserver`` on | |
| * each row that re-dispatches ``hy-chat:updated`` whenever the row's | |
| * height changes (the scroll-lock in ``static/app.js`` uses that | |
| * event to re-evaluate / re-pin). */ | |