Upgrade Storage[iOS] Toggling navigation chrome causes unintended downward scroll / offset shift
Component: Document Viewer / PDF Reader (iPadOS)
Severity: Low - but very very annoying for my usage
Version: 2.0.7 (build 461)
Repro video: https://github.com/user-attachments/assets/b5322200-070a-4159-a062-4f94f960e0db
> This is the first of a few bug reports. Each on its own is minor, but together they add up to a rough experience on iOS, which is otherwise working beautifully.
>
> AI assisted in drafting this report, but the observations come from real use of the app. Code references were located and reviewed to support the described behavior.
Summary
Dismissing the top navigation toolbar and bottom scrubber by tapping the screen causes the document viewport to shift downward rather than preserving the original scroll position. Content that was previously cut off / hidden above the viewport is revealed after the chrome disappears.
Steps to reproduce
1. Open a multi-page PDF/document in full-screen reader mode.
2. Tap the screen once to bring up the top navigation bar and bottom page scrubber.
3. Tap the screen a second time to dismiss the toolbars and return to full screen.
Expected
The page remains at its exact scroll position and vertical offset after the navigation bars disappear.
Actual
The page layout jumps downward (content scrolls down), revealing text above the original view that was previously cut off / hidden off-screen.
Related issues
No existing zotero/zotero-ios issue matches this.
Related forum threads
- PDF reader glitch in iOS / iPadOS (Nov 2023) — an older thread that seems pretty similar. Hard to say if the app has changed too much since then for it to be the same exact issue, but the described behavior matches. https://forums.zotero.org/discussion/comment/448888
- EPUB reader on iPad: top toolbar toggle re-renders/shifts text — the EPUB equivalent of the same toolbar-toggle reflow issue. https://forums.zotero.org/discussion/comment/513698
- iOS: Switching light/dark appearance changes page position (Nov 2022) — same family: a settings change resets the page position. Different trigger, possibly related root cause. https://forums.zotero.org/discussion/comment/422814
Relevant code
The toggle path moves the document container's frame via a layout constraint (documentTop.constant) but never captures or restores the PSPDFKit scroll view's contentOffset around the layout change, so the visible page content shifts with the frame.
- Zotero/Scenes/Detail/PDF/Views/PDFDocumentViewController.swift — toggleUserInterface interaction callback; setInterface(hidden:) (chrome alpha only, no scroll handling).
- Zotero/Scenes/Detail/PDF/Views/PDFReaderViewController.swift — interfaceVisibilityDidChange(to:) (toggles status bar/nav bar, animates layout, no scroll-offset preservation); topDidChange(forToolbarState:) (recomputes documentTop.constant).
- Zotero/Scenes/Detail/PDF/Views/PDFDocumentViewController.swift — on iOS < 26, pdfController.view top is pinned to the safe-area top, so it shifts when the nav bar shows/hides.
- Existing comment in PDFReaderViewController.swift (documentAvailableHeight) notes this scrubber/layout area is already known to be fragile mid-animation.
AI assessment
An AI assistant reviewed the codebase and believes a fix is possible. Its recommendation: capture the PSPDFKit scroll view's contentOffset before the documentTop.constant change in interfaceVisibilityDidChange(to:), and re-apply it after view.layoutIfNeeded() completes in the animation block. It points to the existing pendingCornerTapZoomScale mechanism (which already preserves zoom across corner-tap navigation) and the HTML/EPUB reader's container-insets approach as patterns to model on. I have not verified this recommendation.
Severity: Low - but very very annoying for my usage
Version: 2.0.7 (build 461)
Repro video: https://github.com/user-attachments/assets/b5322200-070a-4159-a062-4f94f960e0db
> This is the first of a few bug reports. Each on its own is minor, but together they add up to a rough experience on iOS, which is otherwise working beautifully.
>
> AI assisted in drafting this report, but the observations come from real use of the app. Code references were located and reviewed to support the described behavior.
Summary
Dismissing the top navigation toolbar and bottom scrubber by tapping the screen causes the document viewport to shift downward rather than preserving the original scroll position. Content that was previously cut off / hidden above the viewport is revealed after the chrome disappears.
Steps to reproduce
1. Open a multi-page PDF/document in full-screen reader mode.
2. Tap the screen once to bring up the top navigation bar and bottom page scrubber.
3. Tap the screen a second time to dismiss the toolbars and return to full screen.
Expected
The page remains at its exact scroll position and vertical offset after the navigation bars disappear.
Actual
The page layout jumps downward (content scrolls down), revealing text above the original view that was previously cut off / hidden off-screen.
Related issues
No existing zotero/zotero-ios issue matches this.
Related forum threads
- PDF reader glitch in iOS / iPadOS (Nov 2023) — an older thread that seems pretty similar. Hard to say if the app has changed too much since then for it to be the same exact issue, but the described behavior matches. https://forums.zotero.org/discussion/comment/448888
- EPUB reader on iPad: top toolbar toggle re-renders/shifts text — the EPUB equivalent of the same toolbar-toggle reflow issue. https://forums.zotero.org/discussion/comment/513698
- iOS: Switching light/dark appearance changes page position (Nov 2022) — same family: a settings change resets the page position. Different trigger, possibly related root cause. https://forums.zotero.org/discussion/comment/422814
Relevant code
The toggle path moves the document container's frame via a layout constraint (documentTop.constant) but never captures or restores the PSPDFKit scroll view's contentOffset around the layout change, so the visible page content shifts with the frame.
- Zotero/Scenes/Detail/PDF/Views/PDFDocumentViewController.swift — toggleUserInterface interaction callback; setInterface(hidden:) (chrome alpha only, no scroll handling).
- Zotero/Scenes/Detail/PDF/Views/PDFReaderViewController.swift — interfaceVisibilityDidChange(to:) (toggles status bar/nav bar, animates layout, no scroll-offset preservation); topDidChange(forToolbarState:) (recomputes documentTop.constant).
- Zotero/Scenes/Detail/PDF/Views/PDFDocumentViewController.swift — on iOS < 26, pdfController.view top is pinned to the safe-area top, so it shifts when the nav bar shows/hides.
- Existing comment in PDFReaderViewController.swift (documentAvailableHeight) notes this scrubber/layout area is already known to be fragile mid-animation.
AI assessment
An AI assistant reviewed the codebase and believes a fix is possible. Its recommendation: capture the PSPDFKit scroll view's contentOffset before the documentTop.constant change in interfaceVisibilityDidChange(to:), and re-apply it after view.layoutIfNeeded() completes in the animation block. It points to the existing pendingCornerTapZoomScale mechanism (which already preserves zoom across corner-tap navigation) and the HTML/EPUB reader's container-insets approach as patterns to model on. I have not verified this recommendation.