LaTeX PDF preview loses position after recompilation

Status: diagnosed by read-only inspection of the installed application bundle; not fixed in the running app. No app files were modified.

Application: ChatGPT/Codex desktop for macOS, version 26.1021.31345, build 21828, bundle ID com.openai.codex.

Reproduction reported

  1. Open a two-page LaTeX document in the built-in source editor and PDF preview.
  2. Scroll the PDF to page 2.
  3. Edit the source and compile.
  4. The refreshed PDF returns to page 1. The user reports that earlier behavior preserved the current position.

Expected: retain the current page, position within the page, and zoom when recompiling the same document. If the page is removed, use the nearest remaining page.

Findings from the installed bundle

Archive inspected: /Applications/ChatGPT.app/Contents/Resources/app.asar.

  • webview/assets/workspace-bce62be12333.js, function vn: the LaTeX workspace passes fileDataUrl: V.dataUrl to PdfPreviewPanel, with autoFocus: false. It does not supply initialPage or onPageChange to retain a page outside the preview.
  • webview/assets/document-371e5e766fab.js, function p: on a new PDF data URL, the loading effect resets the page count to zero, viewport dimensions to null, and the PDF document to null before asynchronously loading the new PDF.
  • webview/assets/pdf-preview-panel-fa6d7aa7a4c3.js, function di: the rendered page elements depend on the loaded PDF and its page count. Clearing the loaded document removes the content providing the scrollable height.
  • webview/assets/paged-thumbnail-rail-layout-bf7942158bc4.js, function U: the initial page defaults to 1. Its pending initial-page ref is cleared after the first layout restoration; it is not rearmed for a new PDF revision. No scroll anchor is restored after compilation.
  • The preview error boundary’s resetKey includes the PDF data URL, but inspection of the boundary shows that changing this key only resets an existing error. It is not evidence that the entire React component remounts on every successful compilation.

These code paths explain a loss of scroll position during reload. Runtime reproduction and validation of a fix remain necessary; computer-use inspection of this app was unavailable.

Required implementation change

Preserve a view anchor for the same document across PDF revisions: current page, normalized offset within that page, horizontal offset, and zoom. Record it while the old layout is available, retain it while the loader has zero pages, and restore it after the new page layout is ready. Suppress transient loading-state page updates so they cannot overwrite the saved position with page 1. Clamp the target when the document shrinks, and reset it only when switching to a different document.

Retaining the last successful page layout during compilation would also avoid the temporary collapse in scrollable height. Restoration should still handle page-size and page-count changes.

Validation needed

  • Recompile after an edit while midway through page 2; preserve page, offset, and zoom.
  • Check both automatic compilation and explicit compilation.
  • Test rapid consecutive edits and failed compilations.
  • Test a changed page size and a document that shrinks below the previously visible page.
  • Switch documents and confirm that positions are isolated by document.

Unsuccessful document-level workaround

Clearing hyperref’s pdfstartpage and pdfstartview did not stop the reset, according to the user. That experimental change was removed. The document compiles successfully without it.