You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: iOS Files preview: PDF renders under the status bar and the header covers the top of the page #21415
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/mobile
Steps to reproduce
Open the iOS app and open a thread in a project that contains a PDF.
Tap Files.
Tap a PDF file to preview it (no download). Reproduced with the IRS Form W-9 (fw9.pdf, 6 pages) and the ResNet paper (resnet.pdf, 12 pages).
Expected behavior
The PDF preview starts below the status bar and the app header, so the top of the first page is fully visible.
Actual behavior
The preview is laid out from the very top of the screen instead of below the safe area and header:
The page counter pill ("1 of 6") sits on top of the iOS status bar and overlaps the clock.
The header (back button, "fw9.pdf", "reflow · samples", "…" menu) floats over the PDF with a blur, and the top of page 1 is underneath it. With fw9.pdf the whole "Form W-9 / Request for Taxpayer Identification Number" title block and lines 1–2 are hidden; the first visible content is line 3a.
Same with a second PDF, resnet.pdf (12 pages): "1 of 12" overlaps the clock, and the paper title "Deep Residual Learning for Image Recognition" sits under the header; the first readable line is the author list.
Impact
Minor bug or occasional failure
Version or commit
2.0.0 (120)
Environment
iPhone, iOS 27.0.1 (24A446)
Logs or stack traces
No response
Screenshots, recordings, or supporting files
Workaround
No response
Related
Same kind of overlap as #15652 (header over thread content on iOS, fixed for the thread view) and #20908 (usage-limits panel under the header).
Confirmed in code on main, so this is accepted as a bug.
In the Files screen, .pdf is routed to the in-place web preview (WorkspaceFileWebPreview), which renders a plain WebView with no top inset. The source text view on the same screen does clear the header: SourceFileSurface uses automatic content insets on iOS plus a top inset from the safe area. The PDF path has neither, so the page and its page counter start at the top of the screen, under the status bar and the header. That matches what you saw with both files.
Related: open #21095 reworks this preview and adds a top inset for PDFs on iOS, but it is not merged, so main still has the overlap. This is the same class of problem as #15652, on a different screen.
Activity
juliusmarminge commentedon Oct 19, 2026
Note
Grok responding on behalf of Julius.
Confirmed in code on main, so this is accepted as a bug.
In the Files screen,
.pdfis routed to the in-place web preview (WorkspaceFileWebPreview), which renders a plain WebView with no top inset. The source text view on the same screen does clear the header:SourceFileSurfaceuses automatic content insets on iOS plus a top inset from the safe area. The PDF path has neither, so the page and its page counter start at the top of the screen, under the status bar and the header. That matches what you saw with both files.Related: open #21095 reworks this preview and adds a top inset for PDFs on iOS, but it is not merged, so main still has the overlap. This is the same class of problem as #15652, on a different screen.