Reader scroll attribution through the observed-top ledger
经由 observed-top ledger 的读者滚动归因
ChatView's bottom-follow recognized only wheel/trackpad gestures as reader input: while pinned to the floor, a scroll event without matching wheel movement was treated as programmatic and snapped back. Touch panning, native-scrollbar dragging, and keyboard paging therefore could not leave the bottom of a streaming transcript — on a phone the tail was effectively locked. That wheel-only input classification was a deli
English
Problem
ChatView's bottom-follow recognized only wheel/trackpad gestures as reader input: while pinned to the floor, a scroll event without matching wheel movement was treated as programmatic and snapped back. Touch panning, native-scrollbar dragging, and keyboard paging therefore could not leave the bottom of a streaming transcript — on a phone the tail was effectively locked. That wheel-only input classification was a deliberate deferral in the sticky-composer note, which rejected a general input state machine "for this narrow fix" and left every other scroll source outside the model.
Decision
Reader input is no longer identified by device. ChatView keeps an observed-top ledger (observedTopRef): the last scrollTop either delivered on the main thread or written by the component, recorded synchronously at every programmatic write site — bottom follow, open restore, prepend anchoring, resize follow, and scroll delivery itself. When a scroll event arrives, a position that deviates from min(ledger, floor) by more than half a pixel is reader input; a position on the ledger (a delayed programmatic delivery) or exactly on the shrunken floor (a browser clamp after content shrank) preserves the current ownership state. Ownership then changes only through reader input under the existing threshold rule: within FOLLOW_THRESHOLD of the floor re-pins, beyond it releases follow and shows Back to bottom. The wheel listener and its epoch bookkeeping are deleted; the component listens to scroll alone, so wheel, touch, scrollbar, keyboard, and any future input source are covered by one rule.
Contract change: coalesced shrink-plus-regrow clamps
A shrink clamp whose layout regrows within the same rendering update before the clamp's scroll event is delivered is geometrically indistinguishable from reader input, so it now reads as the reader and releases follow (Back to bottom recovers). Realistic React-commit-driven shrink and regrow is still absorbed: the layout-effect follow re-pins and re-records the ledger per commit, and a shrink-only clamp lands exactly on min(ledger, floor). Only a non-React reflow that shrinks and regrows inside one update mis-attributes. The previous wheel model kept following in that raced case; the unit contract was rewritten to the absorbed-shrink-only guarantee in the same change.
Testing
Unit specs in packages/client/ui-conversation/tests/chat-view.client.spec.tsx pin the ledger contract directly: a readerScroll helper delivers a position the component never wrote, programmatic deliveries land on the ledger, and the stream-finalization shrink clamp keeps following. Two scenarios in apps/web/tests/chat-scroll-contract.e2e.ts extend the browser e2e lane: keyboard paging over a settled transcript and a touch-style momentum fling against paced streaming, both red under the wheel-only implementation and green under the ledger.
The lane's Chromium cannot synthesize any non-wheel device scrolling, which bounds what the e2e can drive for real: Input.synthesizeScrollGesture with a touch source and hand-rolled Input.dispatchTouchEvent sequences deliver DOM events but never move a scroller (headless and headed-under-Xvfb alike); the default gesture source synthesizes wheel events; and compositor scrollbars ignore synthetic mouse input entirely, with a gutter visible only when --hide-scrollbars is removed. Keyboard is the one working non-wheel primitive, so it carries the real-input-pipeline proof, and the fling scenario replays touch's signature — per-frame decaying displacements the component never authored — through the scrollport directly.
Alternatives considered
Keep the wheel-only model. Rejected: it is the defect. Touch, scrollbar, and keyboard readers cannot take ownership away from a streaming tail, and each newly supported device would need its own carve-out.
Enumerate input devices. Adding touchstart/pointerdown/keydown listeners beside the wheel epoch was the obvious extension. Rejected: native-scrollbar dragging exposes no input event to latch before its scrolls arrive, device lists rot as browsers add sources, and every listener would need its own compositor-delivery grace window — the input state machine the sticky-composer note already declined to build.
Absorb the coalesced shrink-plus-regrow clamp with heuristics. Floor-mismatch grace windows or deferred rAF re-checks could keep the raced clamp from reading as the reader. Rejected: streaming rewrites the floor at chunk pace (24 ms) against ~16 ms frames, so any grace window either swallows genuine touch input during streaming — reopening the bug this change fixes — or is too short to cover the race it targets. The mis-attribution is accepted and recoverable instead.
Drive real touch and scrollbar devices in e2e. Rejected by the environment, not by preference: every synthesis path (CDP touch gestures, touch event sequences, synthetic mouse on classic scrollbars, headed under Xvfb) was probed and cannot scroll; the details live in Testing above.
Consequences
Every reader input owns bottom-follow uniformly, with less code: the wheel listener, its epoch counter, and the pre-input baseline bookkeeping are gone, and attribution rides state the component already maintained. The sticky-composer note's layout, wheel chaining, and prepend-anchoring decisions are untouched and remain authoritative; its wheel-only input rule is superseded by this note. The cost is the contract change above — a coalesced non-React shrink-plus-regrow clamp now pauses follow until the reader returns to the floor or presses Back to bottom — traded for touch, scrollbar, and keyboard correctness during streaming. The e2e lane gains non-wheel coverage only within what its browser can synthesize; if gesture synthesis starts working in a future Chromium, the fling emulation can be replaced by real touch strokes without changing the asserted contract.
中文
问题
ChatView 的贴底跟随此前只把滚轮／触控板手势识别为读者输入：钉在底部（floor）期间，一个没有对应滚轮位移的滚动事件会被视为程序化滚动并被拉回底部。因此触控平移、拖动原生滚动条与键盘翻页都无法离开流式 transcript（文本记录）的底部，在手机上尾部实际上被锁死。这种仅认滚轮的输入来源判定是 sticky-composer 笔记中有意的暂缓：该笔记拒绝为「此次窄范围修复」建立通用输入状态机，把其余所有滚动来源都留在模型之外。
决策
读者输入不再依据设备来识别。ChatView 维护一份 observed-top ledger（observedTopRef）：即最近一次由主线程交付、或由组件自身写入的 scrollTop，并在每一个程序化写入点（贴底跟随、打开时恢复、前置锚定、尺寸变化跟随以及滚动交付本身）同步记录。滚动事件到达时，偏离 min(ledger, floor) 超过半像素的位置即为读者输入；落在 ledger 上的位置（迟到的程序化交付），或恰好落在收缩后底部上的位置（内容收缩后的浏览器钳制），则维持当前的所有权状态。此后所有权只经由读者输入、按既有阈值规则变化：位置距底部在 FOLLOW_THRESHOLD 以内则重新贴底，超出则释放跟随并显示「回到底部」。滚轮监听器及其 epoch 簿记已删除；组件只监听 scroll，因此滚轮、触控、滚动条、键盘以及未来任何输入来源都由同一条规则覆盖。
约定变更：收缩与重新增长被合并的钳制
如果一次收缩钳制的布局在同一次渲染更新内、赶在该钳制的滚动事件交付之前重新增长，那么这个事件在几何上与读者输入无法区分，因此它现在会被判读为读者并释放跟随（可经「回到底部」恢复）。现实中由 React 提交（commit）驱动的收缩与重新增长仍会被吸收：layout effect 中的跟随会在每次提交后重新贴底并重新记录 ledger，而仅收缩的钳制会恰好落在 min(ledger, floor) 上。只有在同一次更新内先收缩再重新增长的非 React 重排会被误归因。旧的滚轮模型在这种竞态情形下会保持跟随；单元测试约定已在同一变更中改写为只吸收纯收缩的保证。
测试
packages/client/ui-conversation/tests/chat-view.client.spec.tsx 中的单元测试直接钉住 ledger 约定：readerScroll 辅助函数交付一个组件从未写入过的位置，程序化交付落在 ledger 上，流收尾阶段的收缩钳制保持跟随。apps/web/tests/chat-scroll-contract.e2e.ts 中的两个场景扩展了浏览器 e2e 车道：在已停稳的 transcript 上做键盘翻页，以及对着按节奏推进的流式输出做一次触控式惯性快滑（momentum fling）；两者在仅认滚轮的实现下均为红、在 ledger 下均为绿。
该车道的 Chromium 无法合成任何非滚轮的设备滚动，这限定了 e2e 能真实驱动的范围：触控来源的 Input.synthesizeScrollGesture 与手工构造的 Input.dispatchTouchEvent 序列都能交付 DOM 事件，却从不移动滚动容器（无头模式与 Xvfb 下的有头模式皆然）；default 手势来源合成的是滚轮事件；合成器滚动条则完全无视合成的鼠标输入，且只有移除 --hide-scrollbars 后才能看到滚动条槽。键盘是唯一可用的非滚轮原语，因此由它承担真实输入流水线的证明；快滑场景则把触控的特征（组件从未写入过的逐帧衰减位移）直接回放进滚动容器。
曾考虑的替代方案
保留仅认滚轮的模型。 否决：它本身就是缺陷所在。触控、滚动条与键盘读者无法从流式尾部夺走所有权，而每种新支持的设备都需要单独开一个特例。
逐一枚举输入设备。 在滚轮 epoch 旁边加挂 touchstart/pointerdown/keydown 监听器是最显而易见的扩展。否决：拖动原生滚动条在其滚动事件到达之前不暴露任何可供锁存的输入事件；设备清单会随浏览器新增输入来源而逐渐腐化；而且每个监听器都需要自己的合成器交付宽限窗口——这正是 sticky-composer 笔记当初就拒绝构建的那个输入状态机。
用启发式吸收收缩与重新增长被合并的钳制。 针对底部失配的宽限窗口，或推迟到 rAF 的复查，本可让这种竞态下的钳制不被判读为读者。否决：流式输出以分片节奏（24 ms）改写底部，而帧间隔约 16 ms，因此任何宽限窗口要么会在流式输出期间吞掉真实的触控输入（重新打开本次变更所修复的缺陷），要么短到盖不住它想针对的竞态。转而接受这一误归因，它是可恢复的。
在 e2e 中驱动真实的触控与滚动条设备。 否决来自环境，而非偏好取舍：每条合成路径（CDP 触控手势、触控事件序列、经典滚动条上的合成鼠标、Xvfb 下的有头模式）都逐一试过，均无法滚动；细节见上文「测试」一节。
后果
每种读者输入现在都以同一方式拥有贴底跟随，而代码更少：滚轮监听器、它的 epoch 计数器以及输入前基线簿记均已移除，归因搭载在组件本就维护的状态之上。sticky-composer 笔记中的布局、滚轮链式处理与前置锚定决策原样保留，仍为权威；其窄范围的输入来源规则由本笔记取代。代价就是上文的约定变更：一次收缩与重新增长被合并的非 React 钳制现在会暂停跟随，直到读者回到底部或按下「回到底部」；以此换来流式输出期间触控、滚动条与键盘的正确性。e2e 车道获得的非滚轮覆盖仅限其浏览器能够合成的范围；若手势合成在未来某个 Chromium 版本中开始可用，可以在不改变所断言约定的前提下，把快滑模拟替换为真实的触控划动。