Correction
The original WCr / ScrollBox measured-line-cache explanation was incorrect. The normal transcript renders its children directly, and renderer traces also ruled out clearBottom(). --stream off and terminal resizing are not reliable workarounds.
Issue
During incremental scrolling, the transcript could become blank while the tab bar, input box, working-directory line, and Working status continued rendering. The failure was reproduced in a 100x24 ConPTY and verified by replaying the raw output through @xterm/headless.
Relevant implementation change
While comparing shipped bundles, I found a renderer change that aligns with the observed behavior. Before 1.0.79-5, the cell renderer applied a detected terminal scroll and shifted its row hashes without marking the affected rows dirty.
Starting in 1.0.79-5, every row in the applied scroll range is additionally marked dirty:
for (let row = scroll.start; row <= scroll.end; row++) {
dirty[row] = true;
}This change is included in stable 1.0.79. It appears relevant because the failure was limited to incremental repainting, but this issue does not establish that it was the maintainers' intended fix or the sole root cause.
Validation
The same prompt, 100x24 ConPTY, capture duration, and replay scorer were used for both versions:
| Version |
Fix present |
Sustained transcript collapse |
1.0.79-4 |
no |
1/3 |
1.0.79 |
yes |
0/3 |
The implementation-change boundary and behavioral results agree. I can no longer reproduce the issue on stable 1.0.79, so I am closing this report. The maintainers may have additional context about whether the renderer change above was intended to address this case.
Correction
The original
WCr/ ScrollBox measured-line-cache explanation was incorrect. The normal transcript renders its children directly, and renderer traces also ruled outclearBottom().--stream offand terminal resizing are not reliable workarounds.Issue
During incremental scrolling, the transcript could become blank while the tab bar, input box, working-directory line, and
Workingstatus continued rendering. The failure was reproduced in a 100x24 ConPTY and verified by replaying the raw output through@xterm/headless.Relevant implementation change
While comparing shipped bundles, I found a renderer change that aligns with the observed behavior. Before
1.0.79-5, the cell renderer applied a detected terminal scroll and shifted its row hashes without marking the affected rows dirty.Starting in
1.0.79-5, every row in the applied scroll range is additionally marked dirty:This change is included in stable
1.0.79. It appears relevant because the failure was limited to incremental repainting, but this issue does not establish that it was the maintainers' intended fix or the sole root cause.Validation
The same prompt, 100x24 ConPTY, capture duration, and replay scorer were used for both versions:
1.0.79-41.0.79The implementation-change boundary and behavioral results agree. I can no longer reproduce the issue on stable
1.0.79, so I am closing this report. The maintainers may have additional context about whether the renderer change above was intended to address this case.