Terminal display corruption: rendered output overlaps/duplicates mid-session #38

Activity

1. AThraen commented on Sep 6, 2026

   

   AThraen

   on Sep 6, 2026

   ContributorAuthor

   More actions

   Related: #116 is the initial-render sibling of this, and it disproves two theories

   Filing a cross-link, because the two look alike and shouldn't be merged.

   • This issue — corruption appearing mid-session, in a running TUI, cleared by resizing.
   • Initial render: input sits one character into the placeholder until the window is resized #116 — a deterministic offset at initial render: the input line is drawn about one character into the placeholder, present from the moment the pane appears, cleared by resizing.

   Same workaround, different trigger, so they're being tracked separately.

   What #116 has established that's relevant here: at startup, xterm and the PTY demonstrably disagree about the column count, and a resize is what reconciles them. That's cause 2 on this issue's likely-causes list ("PTY size drift"), confirmed for at least one code path — which raises its prior for the mid-session case too.

   Two theories are dead and shouldn't be re-tried on either issue:

   1. Font metrics. fix(terminal): re-fit once the font has loaded, not on a timing guess #113 added a re-fit on document.fonts.ready, on the theory that xterm measured the fallback font's advance width before Cascadia Code loaded. It was a no-op — document.fonts.ready resolves once at page load and stays resolved, so the callback ran immediately with identical metrics. fix: release-review findings, verified over three passes #115 replaced it with requestAnimationFrame.
   2. document.fonts.load(). Also a no-op: it matches only CSS-connected FontFace objects, i.e. @font-face rules. There are none — the fonts in play are OS-installed — so it resolves having matched nothing.

   The instrumentation proposed on #116 would serve both: log cols/rows on every fit() and term.onResize page-side, and log what TerminalBridge sets the PTY to. If this issue is size drift, the same trace catches it — with the added question of whether a resize message races an output chunk mid-stream.

   One further datum for cause 4 ("partial recovery from a stall"): the restore loop is now known to stall for seconds at a time under load — measured while investigating #82, where a flat Task.Delay(2000) logged gate=36339ms. If corruption correlates with heavy multi-session activity, that's a real stall to hang the theory on rather than a hypothetical one.
2. AThraen commented on Sep 9, 2026

   

   AThraen

   on Sep 9, 2026

   ContributorAuthor

   More actions

   This was generated by AI during triage.

   Related: #134 — same underlying class of fault (PTY width disagreeing with xterm's rendered width, ink writing to addresses that don't match the visual grid), but at startup rather than mid-session, and with a traced cause: panes attached to the grid without a re-fit outside the Single layout branch, plus term.onResize suppressing a size report when the recomputed cols is unchanged.

   Cause #2 in this issue's list ("PTY size drift — xterm's reported cols/rows and the PTY's value briefly disagree") is exactly what #134 documents, so a fix there may narrow what's left to explain here.