Sign up
View stargazers13Sign up

[Bug]: Files surface jumps scroll focus and throws "Line doesn't exist" with word wrapping activated#7907

openedAug 22, 2026byFfgonzalezurriola

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. Have "word wrap" activated in settings>apperance> word wrap at bottom
  2. Open a file with files surface in the right sidebar (with a lot of collapsable lines, less width => more lines collapsed)
  3. Add more lines
  4. Watch weird behavior with focus - Spamming enter will cause throwing an error

--- CLANKER DIAGNOSTIC BELOW (untested and personally not convinced at first glance, it could be a pierre/diffs issue) ---

The bug is a stale height calculation in the virtualized editor in t3code>apps>web>src>components>files>FilePreviewPanel.tsx.

When wordWrap is enabled:

  1. A logical line can occupy several visual rows, especially at narrow widths.
  2. Pressing Enter invalidates the virtualizer’s cached line heights.
  3. Before the wrapped lines are measured again, the editor tries to reveal the caret and restore scroll.
  4. It estimates positions using the default one-row lineHeight.
  5. That estimate is too small, so the scroll jumps upward. The virtualizer may also recycle the focused DOM row, making the caret appear to disappear.

At wide widths, lines barely wrap, so the estimate is close enough and the bug is hidden. Disabling wrapping removes the variable-height layout entirely, which is why the problem disappears.

Short version: Enter exposes a race between editing, caret scrolling, and remeasuring wrapped virtualized lines.

Expected behavior

Adding a line in a files surface should not mess up with focus and no error should be threw

Actual behavior

Adding a line in a surface with a lot of wrapped lines will cause focus jumps and eventually it will cause throwing an error

Impact

Minor bug or occasional failure

Version or commit

0.0.34-nightly.20260820.1142

Environment

CachyOS, desktop app

Logs or stack traces

shell
1FileRenderer.processFileResult: Line doesnt exist
2Error: FileRenderer.processFileResult: Line doesnt exist
3 at be.processFileResult (t3code://app/assets/DiffCommentAnnotation-DQOJaIPV.js:1:7801)
4 at be.renderFile (t3code://app/assets/DiffCommentAnnotation-DQOJaIPV.js:1:18824)
5 at je.renderPreparedFile (t3code://app/assets/DiffCommentAnnotation-DQOJaIPV.js:1:41228)
6 at je.renderPreparedFile (t3code://app/assets/DiffCommentAnnotation-DQOJaIPV.js:1:17214)
7 at je.onRender (t3code://app/assets/DiffCommentAnnotation-DQOJaIPV.js:1:35788)
8 at computeRenderRangeAndEmit (t3code://app/assets/index-DzSq6vN-.js:1886:73302)
9 at fm (t3code://app/assets/index-DzSq6vN-.js:306:14489)

Screenshots, recordings, or supporting files

2026-08-22_10-19-13.mp4

Workaround

No response

JJulius MarmingeSep 5, 2026

The September 4, 2026 audit found and fixed a separate file-save lifecycle bug in #9878, now on main at b01771c2. React development effect replay had disposed the save coordinator, so real editor changes never reached disk. The PR contains before/after recordings and focused regression tests.

On Linux Chromium 152, the corrected code persisted native typing, a Markdown checkbox, and 60 Enter presses in a wrapped-line control through close/reopen, with no captured browser errors. That smaller control does not establish a fix for this report's larger wrapped-file focus jumps or Line doesnt exist error in the CachyOS desktop app. This issue remains open. A current-version desktop retest with a shareable sample file would help reproduce that exact path.

GPT 6 Astra via Codex in T3 Code.

JJulius MarmingeSep 5, 2026

September 5 audit update: #10018 merged into main at 6270a6f8. It fixes the loss of unchanged wrapped-row measurements during edits and invalidates obsolete measurements when the editor width changes.

In the matched Linux Chromium test, the first Enter in an 8,255-line wrapped file now keeps the new EOF line and caret visible. Native resize controls passed in both directions, along with 55 focused tests. The PR includes before/after recordings.

This issue stays open. Redo and caret scrolling after resize or a line-number digit boundary can still jump; this fix does not change that behavior. The original CachyOS/Electron environment was not exercised. A retest on current main with a shareable sample file and exact remaining action would help narrow those symptoms.

GPT 6 Astra via Codex in T3 Code.

MMnigosSep 7, 2026
Synced from GitHub

Reproduced remaining jumps on current main (dc39615ae), macOS 15.7.5, Chromium 151 web client; desktop/Electron was not used.

Offsets below are CSS pixels; L is the native shadow-DOM selection line. Editor height: 708 px; narrow width: 419 px.

ScenarioActionscrollTop / caret before → afterResult
AEnter ×15, type end52108/L1190 → 52400/L1205Visible, 2/2
BCmd+Z ×852400/L1205 → 52268/L1198Visible
BFirst Cmd+Shift+Z52268/L1198 → 40008/L1001Jump, 2/2
BFinish eight redos40008/L1001 → 62400/L1205EOF restored
CDivider: 619→419→663 px47728/L600 → 34608/L951 → 29408/L951Caret offscreen; 1/3 trials failed
CViewport: 1280→1080→1480 px17728/L600 → 23648/L600 → 20728/L600Visible throughout
DEnter: 999→1000 lines49188/L999 → 29308/L801Caret offscreen, 2/2
DThree more Enters29308/L801 → 49260/L1003EOF restored
EEnter ×10: 1190→120052108/L1190 → 52300/L1200Visible

Reproduce

  1. Download wrap-sample.txt and wrap-sample-999.txt into a project. Each line is 240 characters; neither file has a trailing newline.
  2. Enable Settings → Appearance → Word wrap. At 1280×800, open the Files surface, hide its explorer, and narrow the editor to about 419 px.
  3. Open the fresh 999-line sample, click into the editor, Cmd+End, then Enter once. The first visible line jumps 994→828; the caret stays offscreen after another 700 ms. Three more Enters restore EOF.
  4. Separately, with the fresh 1190-line sample: Cmd+End, Enter ×15 (~120 ms apart), type end, Cmd+Z ×8 (~150 ms apart), then Cmd+Shift+Z once. The view jumps 1186→1001 and stays there until the next redo.

For resize, I scrolled to and clicked line 600 before dragging. The first trial jumped to visible line 1081; two retries passed. Widening was layout-clamped to 663 px. Browser viewport resizing passed.

No Line doesnt exist / Line doesn't exist error or page errors occurred during these scenarios.

Enter, redo, resize and digit-boundary retest

MP4 recording