4.2 KiB
Details-to-Preview native offset loss
2026-09-13, /root/source8_lowering_plan. Read-only source/evidence review at frozen native 44095f78c28b79d6d085863dc928adba8e24d955; no compiler, GUI control or implementation change.
Finding: offset loss contradicts the existing controller's stated intent; it is not an intentional page reset.
crates/oa-desktop/src/app/source_rename.rs:437–439 explicitly says leaving/returning to Preview keeps its selected page and retained scroll, while retiring delayed operations without scheduling return-to-top. Details toggles only visibility, destination visit ID, detail segment and detail content. Actual file/hunk/row/segment changes and changed filters separately request reset; repeated visibility requests are no-ops. The language RST at2142–2149 requires complete preview access and reachable controls outside the independently scrolling source preview, but does not itself explicitly specify the Details round-trip offset. Thus this is a demonstrated implementation-intent regression, not a newly inferred normative language requirement.
I viewed existing frames043 and045 and read their sidecars. Both show proposal assess_report_union_trial, file1/2 sa/reporting.arcadia, hunk1/3 and rows1–7/7. Frame043 is scrolled with line10 and changed declaration line11 visible; frame045 returns to context line8/top. The parent observed the intervening Full details view044. The proposal remains unaccepted. The image evidence supports viewport-offset loss while the logical page remains unchanged.
The apparent implementation mechanism is widget-subtree replacement: dialog_content mounts a Details column/text editor instead of the Preview column/Scrollable (source_rename.rs:1030ff). No preview offset is saved/restored by the Details handler. A new visit ID protects against late operations; it cannot preserve state after the actual Scrollable subtree is discarded. Source review identifies this mechanism; no instrumented widget execution occurred here.
The existing details_round_trip_retires_held_reset_without_changing_page_or_repeated_visibility_scroll regression at preview_scroll_tests.rs:311ff does mount Details in one branch. It verifies zero scheduled reset operations and retained logical page/approval, then scrolls down again after returning before asserting offset retention. Those assertions protect repeated visibility and rejection of a held prior reset, but cannot detect loss of the pre-Details offset. Its passing gate is valid for those narrower assertions and does not falsify this native finding.
Minimal regression before correction: settle a specific preview page, record a nonzero measured offset, toggle Details and actually diff/layout the Details subtree, return/diff/layout Preview, and assert the measured offset equals the recorded value before calling any scroll operation. Preserve same page/approval and complete source/model/history assertions. Retain a fast round-trip branch without an intervening Details mount and the delayed previous-visit reset control. Existing explicit file/hunk/row/segment/filter/new-approval reset tests must keep their reset semantics. An arbitrary return-to-top policy would require an explicit design change rather than relabeling this behavior.
Gitea issue20 was read live through MCP: title Scenario diagrams are very rigid and its controls are bad, owner contribution Codex-ytr83r, latest retrieved comment906 at2026-09-13T08:35:42Z. Its published Saved Scenario spacing/layout candidate is 07e611fb9432b5164e43c326f3e3c7e75e1e6567, then pending compilation/runtime/strict/build/native. That work concerns saved views, spacing and geometry; it supplies no alternate Rename Details scroll policy and is on another machine. Do not import or modify it for this local preview defect. Parent owns integration/publication under the current navigation work.
The earlier local checklist phrase “Details return does not resurrect an old offset” referred to stale delayed-operation isolation, not resetting deliberate current scroll. More precisely: return to the same preview page preserves its user's offset while assigning a fresh operation destination so an old queued reset cannot affect that return visit. Current native evidence has found the first half incomplete.