Undo in the editor renders wrong marks in the F10 review preview #38

New Issue

2026-06-12T10:24:13Z

benstull commented

2026-06-12 10:24:13 +00:00

Undo in the editor renders wrong marks in the F10 review preview

Summary

After pressing undo (Ctrl+Z) in the source editor, the F10 rendered review
preview updates its text but shows incorrect annotations — change-marks,
author-coloring, and/or proposal markup that no longer match the reverted buffer.

Problem / pain

The preview pane re-renders on undo (undo is a document change, so the debounced
onDidChangeTextDocument refresh fires and the text content updates), but the
marks are wrong after the reversal: author-colored spans (cw-by-human /
cw-by-claude), the since-baseline diff, and/or pending-proposal blocks render in
the wrong place or with the wrong content for the post-undo buffer. The text is
right; the overlay that makes the preview a review surface is not. It reproduces
every time on undo in the F10 review preview.

Who feels it

The human coauthor (PP-1) reviewing changes in the preview. Undo is a routine
editing gesture mid-review; when it leaves the marks wrong, the review surface is
actively misleading about what changed and who authored it — the exact thing F10
exists to show truthfully.

Desired outcome / value

After an undo, the preview's marks match the reverted buffer exactly — the
since-baseline diff, author-coloring, and proposal placement are all correct, just
as they are after a normal forward edit. Undo is just another document change; the
review surface stays trustworthy across it.

Acceptance — "done right"

Make an edit with a panel open, then undo it: the preview's marks return to the
correct state for the reverted buffer (no stale/ghost diff, no mis-placed
author-coloring, no orphaned/mis-anchored proposal block).
A sequence of edits + undos leaves the marks consistent with the current buffer
at each step (not just the text).
Redo (Ctrl+Shift+Z) is equally correct (it is the symmetric case).
A regression test reproduces the undo-renders-wrong-marks case and asserts the
corrected marks.

Scope / non-goals

In scope: the F10 review preview's marks (diff / author-coloring / proposals)
staying correct across undo (and redo) of editor changes.

Non-goals: changing the visual language of the marks; the baseline-advance
semantics (INV-18); behavior unrelated to undo/redo.

Assumptions · constraints · dependencies

Defect in shipped F10 (#29) behavior; the preview already refreshes on edit
(trackChangesPreview.ts onEdit → debounced refresh). The render engine
(renderReview) is pure; the wrongness is most likely in the data the refresh
feeds it after an undo (F3 attribution spans and/or F4 proposal anchors not
tracking the reversal), not in the renderer.
Relates to F3 live attribution (#6) and F4 propose/accept (#12) — whichever layer
doesn't reconcile its offsets on undo.

Source / signal

Self-originated — capture session vscode-cowriting-plugin-0033 (2026-06-12),
from a direct operator observation while using the F10 review preview. Symptom
confirmed in-session: "updates but wrong marks," F10 review preview, reproduces
always. Relates to F10 #29, F3 #6, F4 #12.

Priority (WSJF)

Value medium (correctness/trust of the primary review surface; wrong marks
mislead the reviewer) · Time-criticality medium (defect in the just-shipped F10
surface, hit by a routine gesture) · Opportunity low ÷ Size small →
priority/P1 (operator decision, session 0033: undo-during-review is a common
gesture, so a misleading review surface warrants P1). Decision aid, not
auto-scored.

Decomposition

Bug (single corrective increment). Fix checklist:

Reproduce the wrong-marks-after-undo case in a test (unit if the data layer
can be driven directly; host E2E for the editor undo → preview path).
Identify which layer goes stale on undo (F3 attribution spans / F4 proposal
anchors) and reconcile it on the reverting change.
Confirm marks are correct across edit→undo→redo sequences; full unit + E2E
green.

Solution notes (optional — NOT a design)

Non-binding: VS Code delivers undo as an onDidChangeTextDocument with
reason === TextDocumentChangeReason.Undo (redo = .Redo). The preview's onEdit
likely treats it as a normal edit; the suspicion is that the attribution
tracker (F3) or proposal anchoring (F4) does not correctly reverse/re-anchor
its offsets for an undo, so renderReview is handed stale spans/anchors. Worth
checking whether attribution records an undo as a new (mis-attributed) edit
rather than reverting prior spans. Verify before designing a fix.

# Undo in the editor renders wrong marks in the F10 review preview ## Summary After pressing **undo** (Ctrl+Z) in the source editor, the F10 rendered review preview updates its text but shows **incorrect annotations** — change-marks, author-coloring, and/or proposal markup that no longer match the reverted buffer. ## Problem / pain The preview pane re-renders on undo (undo is a document change, so the debounced `onDidChangeTextDocument` refresh fires and the text content updates), but the **marks are wrong** after the reversal: author-colored spans (`cw-by-human` / `cw-by-claude`), the since-baseline diff, and/or pending-proposal blocks render in the wrong place or with the wrong content for the post-undo buffer. The text is right; the overlay that makes the preview a *review* surface is not. It reproduces **every time** on undo in the F10 review preview. ## Who feels it The **human coauthor** (PP-1) reviewing changes in the preview. Undo is a routine editing gesture mid-review; when it leaves the marks wrong, the review surface is actively misleading about what changed and who authored it — the exact thing F10 exists to show truthfully. ## Desired outcome / value After an undo, the preview's marks match the reverted buffer exactly — the since-baseline diff, author-coloring, and proposal placement are all correct, just as they are after a normal forward edit. Undo is just another document change; the review surface stays trustworthy across it. ## Acceptance — "done right" - Make an edit with a panel open, then undo it: the preview's marks return to the correct state for the reverted buffer (no stale/ghost diff, no mis-placed author-coloring, no orphaned/mis-anchored proposal block). - A sequence of edits + undos leaves the marks consistent with the current buffer at each step (not just the text). - Redo (Ctrl+Shift+Z) is equally correct (it is the symmetric case). - A regression test reproduces the undo-renders-wrong-marks case and asserts the corrected marks. ## Scope / non-goals **In scope:** the F10 review preview's marks (diff / author-coloring / proposals) staying correct across undo (and redo) of editor changes. **Non-goals:** changing the visual language of the marks; the baseline-advance semantics (INV-18); behavior unrelated to undo/redo. ## Assumptions · constraints · dependencies - Defect in shipped F10 (#29) behavior; the preview already refreshes on edit (`trackChangesPreview.ts` `onEdit` → debounced `refresh`). The render engine (`renderReview`) is pure; the wrongness is most likely in the **data the refresh feeds it** after an undo (F3 attribution spans and/or F4 proposal anchors not tracking the reversal), not in the renderer. - Relates to F3 live attribution (#6) and F4 propose/accept (#12) — whichever layer doesn't reconcile its offsets on undo. ## Source / signal Self-originated — **capture session vscode-cowriting-plugin-0033** (2026-06-12), from a direct operator observation while using the F10 review preview. Symptom confirmed in-session: "updates but wrong marks," F10 review preview, reproduces always. Relates to F10 `#29`, F3 `#6`, F4 `#12`. ## Priority (WSJF) Value **medium** (correctness/trust of the primary review surface; wrong marks mislead the reviewer) · Time-criticality **medium** (defect in the just-shipped F10 surface, hit by a routine gesture) · Opportunity **low** ÷ Size **small** → **priority/P1** (operator decision, session 0033: undo-during-review is a common gesture, so a misleading review surface warrants P1). Decision aid, not auto-scored. ## Decomposition Bug (single corrective increment). Fix checklist: - [ ] Reproduce the wrong-marks-after-undo case in a test (unit if the data layer can be driven directly; host E2E for the editor undo → preview path). - [ ] Identify which layer goes stale on undo (F3 attribution spans / F4 proposal anchors) and reconcile it on the reverting change. - [ ] Confirm marks are correct across edit→undo→redo sequences; full unit + E2E green. ## Solution notes (optional — NOT a design) Non-binding: VS Code delivers undo as an `onDidChangeTextDocument` with `reason === TextDocumentChangeReason.Undo` (redo = `.Redo`). The preview's `onEdit` likely treats it as a normal edit; the suspicion is that the **attribution tracker** (F3) or **proposal anchoring** (F4) does not correctly reverse/re-anchor its offsets for an undo, so `renderReview` is handed stale spans/anchors. Worth checking whether attribution records an undo as a *new* (mis-attributed) edit rather than reverting prior spans. Verify before designing a fix.

benstull added the priority/P1 type/bug labels 2026-06-12 10:24:13 +00:00

benstull referenced this issue from a commit

2026-06-12 10:37:28 +00:00

fix #38: don't mis-attribute undo/redo as fresh human authorship in the preview

benstull referenced a pull request that will close this issue

2026-06-12 10:37:41 +00:00

fix #38: undo/redo no longer mis-attributes restored text in the review preview #39

benstull closed this issue

2026-06-12 10:37:49 +00:00

benstull referenced this issue from a commit

2026-06-12 10:37:49 +00:00

Merge pull request 'fix #38: undo/redo no longer mis-attributes restored text in the review preview' (#39) from bug/38-undo-wrong-marks-in-preview into main