Open a document at the top of its own first page - #167
Merged
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a12787b7f2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
The script that fits a wide page to the screen runs at document end, while the web view still has its storyboard width of 414 points. It measured the page at 826 pixels, called that wider than the screen, and pinned the viewport to that width. An iPad then lays out at 1032 - wider than the page, which therefore never needed pinning - and the re-anchor across that resize left the page 137 pixels down. Far enough to take the heading off a pdf or a Word document. The width now comes from the visual viewport, which reports the web view's own width whatever viewport we name, and it is measured again on every resize, so a rotation gets the same answer. A page that fits is handed back the viewport odrcore served. Measured on both devices: the iPad settles at width=device-width, zoom 1, scroll 0, where it sat 137 pixels down before; the iPhone keeps width=826 at zoom 0.53, which is the fitting this is for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E6tn8P25cBDmrA67zrhfwN
andiwand
force-pushed
the
open-a-document-at-its-top
branch
from
August 17, 2026 10:55
a12787b to
9588596
Compare
andiwand
enabled auto-merge (squash)
August 17, 2026 10:57
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A pdf or a Word document opened part way down its own first page, with the heading cut off. On an iPad, every time.
What was wrong
fitToWidthScriptis injected at document end, which is before the web view has the size it will keep — at that moment it still has its storyboard width of 414 points. So it measured the page at 826 CSS pixels, concluded "wider than the screen", and pinned the viewport towidth=826.The iPad then lays out at 1032 points. That is wider than the page, so the page never needed pinning at all; and WebKit re-anchors the scroll across the resize, which left the document 137 pixels down. Enough to lose the invoice number on a pdf and the heading on a Word file.
The iPhone escaped it because 440 points really is narrower than 826, so the early answer happened to be right.
What it does now
The available width comes from
visualViewport.width * scale, which stays equal to the web view's own width no matter what viewport we have named — so the decision can be re-taken at any time without being confused by its own previous answer. It is re-taken on everyresize, which also fixes rotation, and a page that fits is handed back the viewport odrcore served.Measured, not inferred
I instrumented the view and read the numbers off both devices rather than guessing from screenshots — three plausible-looking fixes had already failed because the scroll appears between 0.1s and 0.5s, after any of them ran.
width=826, zoom 1.25, scroll 137width=device-width, zoom 1.0, scroll 0width=826, zoom 0.53, scroll 0Split out of #164, which is stacked on this — the iPad screenshots are wrong without it, but the bug has nothing to do with screenshots and shouldn't wait behind them.
🤖 Generated with Claude Code