getViewport() returns corrupted data when viewport spans multiple pages

[darrinm]

Description

renderStateGetViewport in the WASM build resolves the viewport top-left position independently for each row using pages.pin(.active). When the viewport spans multiple internal pages, this per-row resolution can produce inconsistent results, leading to corrupted viewport data.

Additionally, scrollbackLimit is passed as a line count but Terminal.init() interprets max_scrollback as bytes, causing the scrollback buffer to be much smaller than intended and making the page-spanning condition occur more frequently.

Symptoms

• getScrollbackLength() drops unexpectedly (e.g., 498 → 269) after repeated writes
• getViewport() returns rows with content from different terminal lines merged together
• Both getViewport() and getLine() return the same wrong data
• Corruption frequency depends on column width:
  • cols=80: OK
  • cols=120: CORRUPT
  • cols=130: CORRUPT
  • cols=140: OK
  • cols=160: scrollback drops but viewport may appear OK (merge lands on empty rows)

Root cause

The native Ghostty renderer reads cell data from cached row pins in RenderState.row_data (built during update()), which guarantees consistent page resolution across all viewport rows. The WASM renderStateGetViewport instead calls pages.pin(.active) per-row, which can resolve to different pages inconsistently when the viewport straddles a page boundary.

Reproduction

1. Create a terminal at cols=130, rows=39, scrollback=10000
2. Repeatedly write ~68 lines of escape-heavy output (SGR 256-color, truecolor, attributes)
3. After ~8 repetitions, call getScrollbackLength() and getViewport()
4. Scrollback length will drop and/or viewport rows will contain merged content

Expected behavior

getViewport() should return consistent, correct row data regardless of internal page layout. scrollbackLimit should be interpreted consistently between the JS config and WASM init.

Fix

Draft PR with fix and regression tests: #133

[diegosouzapw]

Hi @darrinm! 👋

Just wanted to let you know: this issue is fixed in diegosouzapw/ghostty-web v0.4.0 (see commit).
renderStateGetViewport now uses cached row pins from RenderState.row_data (matching the native renderer), and the scrollback limit is correctly converted from line count to bytes.

If you're looking for a fork with this and many other upstream fixes, feel free to give it a try!

I'm also building OmniRoute, an open project that provides free LLM model access — I plan to use ghostty-web there, so the more reliable it gets, the better. 🙏 Contributions welcome!

[ThomasK33]

Note

This triage report is AI-generated using Mux

1. Classification — bug; confirmed locally. No outcome label is recommended because the behavior reproduced.

2. Summary — getViewport()/getLine() can return corrupted viewport rows after repeated escape-heavy writes when the viewport crosses Ghostty's internal page boundaries. The same scenario also shows getScrollbackLength() decreasing unexpectedly even though new output is only appended. This matches the issue's report that viewport row resolution is inconsistent across pages and that the JavaScript scrollback line count is passed to WASM as if it were Ghostty's byte-based max_scrollback value.

3. Evidence / reproduction — I reproduced this against the current checkout at 6a1a50d after installing dependencies and building the WASM artifact:

   bun install
   PATH="$(mise where zig@0.15.2):$PATH" ./scripts/build-wasm.sh
   bun test lib/issue-139-triage-repro.test.ts

   The local repro creates terminals with rows=39, scrollback=10000, repeatedly writes generated SGR-heavy output (256-color blocks, truecolor gradients, attributes, and Unicode box drawing), calls term.wasmTerm!.update(), then checks scrollback monotonicity and viewport stability.

   Observed failing output excerpt

   scrollback lengths: 26, 90, 154, 218, 282, 346, 410, 474, 538, 306, 370, 434
   Expected: >= 538
   Received: 306
   
   max viewport diff rows: 4
   Expected: <= 1
   Received: 4
   
   0 pass
   2 fail
   

   A targeted existing consistency test still passes (bun test lib/terminal.test.ts -t "getViewport and getLine return consistent data"), which suggests the existing test coverage does not exercise the multi-page scrollback/viewport boundary case.

4. Relevant code / likely cause — The observed failures line up with the source paths named in the issue:

   • patches/ghostty-wasm-api.patch defines renderStateGetViewport() by looping over viewport rows and calling pages.pin(.{ .active = .{ .y = ... } }) per row before reading pin.cells(.all). That bypasses the already-updated render-state row cache.
   • Native Ghostty RenderState.update() stores stable viewport row pins in ghostty/src/terminal/render.zig (row_data.items(.pin)), specifically so callers can use one coherent viewport mapping.
   • lib/terminal.ts passes the user-facing scrollback option into GhosttyTerminalConfig.scrollbackLimit, lib/ghostty.ts writes that value directly into the WASM config, and patches/ghostty-wasm-api.patch forwards it as .max_scrollback to Terminal.init().
   • ghostty/src/terminal/Screen.zig documents max_scrollback as bytes, not lines, so scrollback: 10000 is currently a much smaller buffer than the API name implies.

5. Recommendation — Keep this open as a confirmed bug and move the existing draft fix in fix: use cached row pins for WASM viewport rendering #133, or an equivalent patch, forward. The implementation should (a) make the WASM viewport getter read from cached RenderState.row_data row pins built by renderStateUpdate() rather than resolving each row independently, (b) convert the JavaScript scrollback line count to a byte budget before passing max_scrollback into Ghostty, and (c) add regression tests covering the monotonic scrollback and repeated-write viewport stability cases above.

6. Adjacent issues — No exact duplicate was found in a search for viewport/scrollback corruption. No new adjacent issue was created.

---

Generated with mux • Model: openai:gpt-5.5 • Thinking: xhigh