[BUG] Diff view scroll position not preserved -- viewport jumps on open and after Save/Deny

[awschmeder]

[BUG] Diff view scroll position not preserved -- viewport jumps on open and after Save/Deny

Problem (one or two sentences)

When Zoo Code applies a file edit and opens the diff editor, the viewport is not reliably
positioned at the changed region. After the user clicks "Save" or "Deny", the viewport
always jumps to the top of the file, destroying their scroll position.

---

Context (who is affected and when)

Affects all users working on files longer than a screen height. The disruption compounds
in long files and in sessions with many edits. Two distinct failure points:

1. The diff editor opens at the wrong scroll position -- behavior depends inconsistently
   on whether the edit is a pure addition, pure deletion, or mixed.
2. After clicking "Save" or "Deny", the viewport unconditionally resets to the top of
   the file, regardless of where the user was before the diff appeared.

Additionally, files that were not already open before the diff are left as open tabs
after Save/Deny, polluting the user's tab bar.

---

Reproduction steps

Note: When testing manually, instruct Zoo to use the diff tool so that it does not attempt to use shell commands to apply the edits.

Scenario A -- file is ALREADY OPEN in the editor

Operation	Diff scroll behavior
Add 1 line at end	Does NOT scroll to change
Remove 1 line at end	Does NOT scroll to change
Remove 1 line + add 1 line	DOES scroll to change

Steps:

1. Open a file of several hundred lines in VS Code.
2. Ask Zoo Code to append a line near the end of the file (pure addition).
3. Observe: diff editor opens with viewport at the top, not the changed line.
4. Click "Save" or "Deny".
5. Observe: viewport jumps to the top of the file.
6. Repeat steps 2-5 with a pure deletion and then a mixed remove+add edit.

Scenario B -- file is NOT already open

Operation	Diff scroll behavior
Remove 1 line at end	Opens file -- does NOT scroll to change
Add 1 line at end	Opens file -- scrolls to end (correct)
Remove 1 line + add 1 line	Opens file -- does NOT scroll to change

Steps:

1. Close the target file if it is open.
2. Ask Zoo Code to edit a region near the end of the file.
3. Observe: diff editor opens; viewport position depends on operation type (see table).
4. Click "Save" or "Deny".
5. Observe: viewport jumps to the top. The file tab remains open even though it was not
   open before Zoo Code intervened.

---

Expected result

• The diff editor always opens with the viewport positioned at the first changed line,
  regardless of whether the change is a pure addition, pure deletion, or mixed.
• After "Save": if the file was open before the diff, the viewport is restored to its
  pre-diff scroll position. If the file was not open before, the tab is closed.
• After "Deny": same behavior as "Save".

---

Actual result

• The diff editor inconsistently positions the viewport. Pure additions and pure
  deletions do not scroll to the change; only mixed (remove + add) edits sometimes do.
• After "Save" or "Deny", the viewport always resets to the top of the file.
• Files that were not previously open remain as open tabs after Save/Deny, polluting the
  tab bar.

---

Variations tried

Occurs regardless of API provider or model. Observed with both write_to_file and
apply_diff tool calls.

---

App Version

(fill in current Zoo Code version before filing)

---

API Provider

Not Applicable -- reproducible with any provider and model.

---

Upstream prior art

This is a long-standing unresolved bug inherited from the Roo-Code codebase. Related
upstream issues (none resolved, none fixed):

Scroll / viewport

Issue	Title	Status
RooCodeInc/Roo-Code#8112	Preserve viewport when applying diffs to the active editor (avoid re-open)	OPEN
RooCodeInc/Roo-Code#12084	After each modification is completed, the mouse/focus jumps to the top of the code	OPEN
RooCodeInc/Roo-Code#10142	Diff view does not auto-scroll to bottom when streaming long content	OPEN
RooCodeInc/Roo-Code#9282	Restore editor scroll position after closing diff view	CLOSED (no fix)
RooCodeInc/Roo-Code#6853	Diffs do not return to cursor position	CLOSED (no fix)
RooCodeInc/Roo-Code#7996	File scroll to edit location after "User Edits" in diff	CLOSED (narrow scope)

Tab management (related UX degradation)

Issue	Title	Status
RooCodeInc/Roo-Code#6003	Auto-close Roo Tabs	CLOSED (no fix)
RooCodeInc/Roo-Code#11326	Pinned tabs are unpinned when edited by RooCode	OPEN
RooCodeInc/Roo-Code#6010	Add option to disable/enable focus on diff view	CLOSED (no fix)
RooCodeInc/Roo-Code#6005	Open Tabs in Correct Tab Group if Auto Focus Disabled	CLOSED (no fix)

Root cause note (from #8112)

Re-opening the document via the VS Code diff API resets the viewport to line 1.
When the target file is already the active editor, re-opening it resets the scroll
position unconditionally. The prescribed fix: when the target file is the currently
active editor, avoid re-opening it; apply the change in-place to preserve the viewport.
When the file is not already open, continue using the diff UI but scroll the diff
editor to the first changed line before displaying it.

The upstream proposal for tab cleanup (#6003) introduced a PostEditBehaviorUtils class
inside DiffViewProvider to centralize post-edit tab tracking and closure, with two
user settings (autoCloseRooTabs, autoCloseAllRooTabs) -- but this was never merged.

[awschmeder]

diff-scroll-handling-compressed.mp4

[navedmerchant]

I have noticed this very annoying issue. Thanks for filing and finding a good testcase for it!