The HTML core serves carries <meta name="viewport" content="width=device-width"> and no scale, so a page wider than the screen is left to overflow. Both apps then patch that themselves — Android through loadWithOverviewMode, iOS by rewriting the meta tag from a user script — and both have had bugs from it.
The iOS one, just fixed there: a document is loaded into a web view still at its storyboard width and laid out again at the real one a moment later. The browser answers that resize by keeping whatever was against the top of the screen, and gets it wrong, because the scale changes with the width — the page comes back hundreds of pixels down, a page or more into a long document on an iPad. It settles there a few frames after the resize, so nothing done in the same breath holds it; the app now re-asserts the reading position over the next half second.
Two things worth separating:
- Fitting. Rewriting a meta tag is the weakest lever there is — some browsers ignore it, and every host has to reimplement the same judgement. Core knows the page's real width and lays it out, so it could serve something that simply fits: a scaled wrapper, or a layout that reflows to the viewport.
- Holding the reading position across a resize. This is the half that actually bit, and it is not a meta-tag problem: with the iOS rewriting switched off entirely, the page still jumped. Whatever core serves would want to keep the reader's place when the viewport changes, rather than leaving each app to fight the browser's own guess.
No rush from our side — iOS is patched and Android has its own workaround. Filing it so the fix has one home rather than two.
Context: opendocument-app/OpenDocument.ios#179, and opendocument-app/OpenDocument.ios#167 before it.
The HTML core serves carries
<meta name="viewport" content="width=device-width">and no scale, so a page wider than the screen is left to overflow. Both apps then patch that themselves — Android throughloadWithOverviewMode, iOS by rewriting the meta tag from a user script — and both have had bugs from it.The iOS one, just fixed there: a document is loaded into a web view still at its storyboard width and laid out again at the real one a moment later. The browser answers that resize by keeping whatever was against the top of the screen, and gets it wrong, because the scale changes with the width — the page comes back hundreds of pixels down, a page or more into a long document on an iPad. It settles there a few frames after the resize, so nothing done in the same breath holds it; the app now re-asserts the reading position over the next half second.
Two things worth separating:
No rush from our side — iOS is patched and Android has its own workaround. Filing it so the fix has one home rather than two.
Context: opendocument-app/OpenDocument.ios#179, and opendocument-app/OpenDocument.ios#167 before it.