Problem
HTML file tabs do not preserve the user's scroll position when the tab is hidden and later reselected. If a user opens an HTML document, scrolls down, switches to another tab, and then returns to the HTML tab, the document is shown from the top again instead of the position where the user left it.
Reproduction
- Open a vault file that is rendered with the
html file viewer.
- Scroll down inside the HTML preview.
- Switch to another editor tab in the same pane.
- Switch back to the HTML tab.
Expected behavior
The HTML preview should restore to the same scroll position the user left, including deep positions in long generated/exported documents.
Actual behavior
The iframe reloads/recreates and the document starts at the top.
Code context
apps/desktop/src/features/editor/HtmlTabView.tsx renders HTML previews as a plain iframe with src={previewUrl} and key={previewUrl}. There is currently no capture/restore path for the iframe document scroll state.
apps/desktop/src/features/editor/FileTabView.tsx renders HtmlTabView key={tab.id} for tab.viewer === "html".
apps/desktop/src/features/editor/EditorPaneContent.tsx keeps some tab surfaces alive while hidden (Editor, graph, terminal), but generic file/pdf panel views are only rendered for the currently active tab through renderEditorPanelView(...). This means the HTML iframe is unmounted when another tab becomes active.
- PDF tabs already solve the same class of problem by persisting scroll state in the tab model:
PdfTabView captures scroll changes and calls updatePdfScrollPosition, while editorWorkspace stores scrollTop/scrollLeft on the current PDF history entry.
- File tabs currently persist file identity/viewer metadata, but not per-viewer UI state such as HTML iframe scroll.
Likely fix direction
Add HTML viewer scroll persistence instead of relying on the iframe staying mounted. A clean fix probably needs a small bounded refactor around file viewer state so HTML can store and restore scrollTop/scrollLeft similarly to PDF, without bolting a one-off global cache onto HtmlTabView.
Possible approaches:
- Extend the file tab/history model with viewer-specific UI state for HTML scroll position.
- Add store actions similar to
updatePdfScrollPosition, scoped to file/html tabs.
- In
HtmlTabView, capture scroll from the iframe's same-origin document before unmount and on iframe scroll/load, then restore after load.
- Add focused tests around switching away from an HTML tab and returning to it.
Acceptance criteria
- Switching away from an HTML tab and back restores the previous scroll position.
- Closing/reopening or session restore behavior is intentionally decided and covered by tests, rather than accidental.
- The implementation does not regress PDF scroll persistence or note/editor hidden-tab state.
- The fix is robust for vault-served HTML documents loaded through
buildVaultAssetUrl.
Problem
HTML file tabs do not preserve the user's scroll position when the tab is hidden and later reselected. If a user opens an HTML document, scrolls down, switches to another tab, and then returns to the HTML tab, the document is shown from the top again instead of the position where the user left it.
Reproduction
htmlfile viewer.Expected behavior
The HTML preview should restore to the same scroll position the user left, including deep positions in long generated/exported documents.
Actual behavior
The iframe reloads/recreates and the document starts at the top.
Code context
apps/desktop/src/features/editor/HtmlTabView.tsxrenders HTML previews as a plain iframe withsrc={previewUrl}andkey={previewUrl}. There is currently no capture/restore path for the iframe document scroll state.apps/desktop/src/features/editor/FileTabView.tsxrendersHtmlTabView key={tab.id}fortab.viewer === "html".apps/desktop/src/features/editor/EditorPaneContent.tsxkeeps some tab surfaces alive while hidden (Editor, graph, terminal), but genericfile/pdfpanel views are only rendered for the currently active tab throughrenderEditorPanelView(...). This means the HTML iframe is unmounted when another tab becomes active.PdfTabViewcaptures scroll changes and callsupdatePdfScrollPosition, whileeditorWorkspacestoresscrollTop/scrollLefton the current PDF history entry.Likely fix direction
Add HTML viewer scroll persistence instead of relying on the iframe staying mounted. A clean fix probably needs a small bounded refactor around file viewer state so HTML can store and restore
scrollTop/scrollLeftsimilarly to PDF, without bolting a one-off global cache ontoHtmlTabView.Possible approaches:
updatePdfScrollPosition, scoped to file/html tabs.HtmlTabView, capture scroll from the iframe's same-origin document before unmount and on iframe scroll/load, then restore after load.Acceptance criteria
buildVaultAssetUrl.