The live fit is gated on being in a frame, so a top-level host can only have it frozen (`viewport_width`)

[andiwand]

Filing this from the Android side after taking 6.10.0 (opendocument-app/OpenDocument.droid#609). Short version: the app wired viewportWidth, measured a regression, and reverted it — and the reason generalises past Android.

What Android has today, and where it comes from

PageView is a top-level WebView with useWideViewPort and loadWithOverviewMode set. Those two make the WebView pick a page scale that fits the content, but only where the page has not pinned one — and that is exactly the distinction write_viewport_meta already draws:

view	meta tag	what the WebView does
fit_width (slide, pdf page, text document with margins)	width=device-width,user-scalable=yes	scales the page down to fit, at load and again on every rotation
actual_size (sheet, plain text, xml, archive listing)	width=device-width,initial-scale=1.0,user-scalable=yes	holds 1:1, content overflows to the right

Measured on 6.10.0, API 36 / WebView 133 and API 31 / WebView 91: style-various-1.pptx fills the width in portrait, and fills it again after a turn to landscape; file_example_XLSX_50.xlsx sits at full size with column D cut off at the edge.

So the fit on Android is already core's decision, executed by the host — not a workaround of the kind iOS carries (#706). The absent initial-scale is doing real work.

What happens if Android takes viewport_width

Wired end to end through CoreLoader, built, and measured against the same documents:

• At load: no visible change. The WebView was already fitting; the css factor just moves who applies it.
• After a rotation: a regression. --odr-fit becomes a number, so measures is false in viewport_js and resized() returns after remember(). The factor was decided while translating and cannot follow the viewport. A deck opened in portrait keeps a portrait-sized slide centred in a landscape screen — where before it filled the width.

Reverted. The droid PR takes 6.10.0 and sets neither viewportWidth nor initialZoom.

The general shape

framed is a proxy for "will the host fit this for me":

// Only a frame is fitted here: the viewport meta tag covers the top-level
// document but is inert in a frame.
var framed = window.top !== window.self;

That proxy is wrong in both directions once you leave the browser:

• top level + Android WebView with loadWithOverviewMode → the host fits, live
• top level + WKWebView → it does not, which is why the iOS app rewrites the meta tag from a user script (Served pages leave fitting to the app, and each app gets it wrong differently #706)
• top level + a desktop browser → it ignores the tag altogether
• framed → it does not

The page cannot test the thing the guard is testing. Only the host knows. Which leaves three modes where four are wanted:

1. the host fits it, via the meta tag — today's top-level default
2. a static css factor — viewport_width
3. the view measures itself, live — framed only
4. the view measures itself, live, at top level — missing

Suggestion

Let a host ask for (4) explicitly: a flag meaning "fit paged output, measured by the view", which drops the framed guard for that document and leaves --odr-fit: auto. viewport_width keeps its own meaning — "I already know the width, write it into the css" — which is still the right answer for an embedder under a CSP that cannot run the script.

Worth keeping it opt-in rather than widening the default: the guard is there because fitting every fit_width view at load moved 86 of 377 public reference renders, and shrinking a wide page in a desktop window is not what #706 or #708 asked for. An opt-in disturbs neither.

Is it worth doing?

Honest answer, from the side that just declined to use it:

• iOS: yes. WKWebView has no loadWithOverviewMode equivalent, so top-level output is not fitted at all and the app patches it by rewriting the meta tag. (4) would delete that workaround. Note that (2) would not — it would hand iOS the same frozen-on-rotation behaviour Android just measured, on a device people rotate at least as often.
• Embedders: already served by (3). Nothing to do.
• Android: no, not as a fix. The WebView already does (4), live, steered by core's own per-view decision. Adopting a core-side fit would mean turning loadWithOverviewMode off and handing the job over. Two things it would buy, both small:
  • Core fits the page box (page plus gutter); the WebView fits the content. A document with a table wider than its page makes the WebView zoom right out and the body text tiny, where core would fit the page and let the table overflow — the better read. Reasoned from both sides, not measured: no fixture in the corpus mixes the two widths.
  • The anchor logic in viewport_js would hold the reading position across a rotation exactly. The browser's own guess drifted about one line in a long .odt here — Served pages leave fitting to the app, and each app gets it wrong differently #706's "a page or more" was the iOS resize, and Android's guess is much better than that.

So: worth doing for iOS, and for having one answer to this instead of three. Not worth doing for Android's rendering. If it lands, droid would adopt it to drop loadWithOverviewMode and to get page-box fitting — not because anything is broken.

Environment

odrcore 6.10.0 (app.opendocument:odr-core-android from maven central), OpenDocument.droid at opendocument-app/OpenDocument.droid#609. Emulators: API 36 / WebView 133.0.6943.137 and API 31 / WebView 91.0.4472.114. Documents: test/data/input/odr-public/pptx/style-various-1.pptx, odt/about.odt, xlsx/file_example_XLSX_50.xlsx.

[andiwand]

From the iOS side, having built the same wiring, measured it and reverted it (opendocument-app/OpenDocument.ios#180). The analysis holds and (4) is what this app wants. One thing is missing, and it lands squarely on (4) rather than on (2).

(4) applies body{zoom}, and WKWebView does not report rects in that space

viewport_js applies the measured fit as body.style.zoom. On WebKit the zoom is applied to layout — the fit is real — but getBoundingClientRect() returns unzoomed coordinates while elementFromPoint() works in the real viewport. The two spaces differ by exactly the applied zoom.

A real document fitted through viewport_width, iPhone 17 / iOS 26 simulator, viewport 390, applied zoom 0.472155:

	value
documentElement.clientWidth	390
documentElement.scrollWidth	390, and 826 with the zoom reset — the fit works
body.getBoundingClientRect().width	826
elementFromPoint at a run's rect centre	nothing
same point × the zoom	the run

And synthetically, body at zoom: 0.5, an element laid out at left: 40px; top: 100px; width: 200px:

	value
getComputedStyle(body).zoom	"0.5"
a 100px probe measured through getBoundingClientRect()	100
the element's rect	[40, 100, 200] — raw layout coords
elementFromPoint at rect coords	the wrong element
at rect coords × 0.5	the right one

body.scrollWidth is unaffected by the zoom here (826 either way), so contentWidth() is fine.

What breaks is anchor() / restore(), which mix the two spaces directly: elementFromPoint(x, y) picks the element visually at the top of the viewport, getBoundingClientRect() then describes it hundreds of unzoomed pixels away, so intoY comes out meaningless and restore() scrolls by a bogus delta. Today this is invisible on iOS because top-level is never fitted — measureFit() returns 1 and the zoom stays 1, so the spaces coincide. (4) is what would introduce it. Which means (4) as proposed would delete the meta-tag workaround and break the reading-position anchor in the same step.

Also worth checking on Android before this lands: WebView 91 predates Chromium's standardised zoom (128), where rects did not include it either. WebView 133 will be clean, which is likely why nothing showed up in the (2) run — nothing there tapped or anchored.

Fix, if it helps

The conversion factor is feature-detectable in-page, no engine sniffing:

// how much of the applied zoom this engine already reports in rects
function rectScale() {
  var probe = document.createElement("div");
  probe.style.cssText = "position:absolute;top:0;left:0;width:100px;height:100px";
  body.appendChild(probe);
  var scale = probe.getBoundingClientRect().width / 100;
  body.removeChild(probe);
  return scale;
}

Rect coordinates × applied / rectScale() are viewport coordinates. Verified above: it picks the right element on WebKit, and on an engine that already includes the zoom the factor is 1, so the same code changes nothing there.

Smaller, separate: the pinned branch discards the reading position

Not just "the factor cannot follow the viewport" — the place is lost too. resized() assigns width before it delegates:

var target = held;
width = root.clientWidth;
if (pinned !== null || !measures) {
  remember();   // clientWidth === width now, so held = anchor() — post-relayout
  return;
}

remember() takes the assignment branch and overwrites held with an anchor read after the browser has already relaid out and moved the scroll, so target is dropped and the pre-change position is gone. This bites mode (2) on any host that rotates, and any host re-pinning with setZoom on rotation — which is the only way to re-fit a stated fit today, so the two compound.

Confirming the iOS half

• No loadWithOverviewMode equivalent, correct. width=device-width alone is read as "lay out at screen width, let the rest overflow", so nothing is fitted.
• What the app does instead: a user script rewrites the meta tag to width=<content width> when the content is wider than the viewport, and restores the served tag when it is not, re-running on every resize — plus its own scroll-holding, because the browser's guess across that change was off by a page or more on an iPad. So the same judgement reimplemented, exactly as Served pages leave fitting to the app, and each app gets it wrong differently #706 says.
• (4) would delete all of it, and only (4) — the app rotates, so (2) freezes it, same as Android measured.

[andiwand]

Three things from the iOS pull request (opendocument-app/OpenDocument.ios#180) that my comment above left out.

A transform instead of zoom

I offered the correction — rect coordinates × applied / rectScale() — and not the other way out, which is the one I would look at first: apply the fit as a transform rather than as zoom. A transform is included in getBoundingClientRect() on every engine, so the two spaces never come apart and there is nothing to detect and nothing to correct in script. It costs the layout reflow zoom gives — a transformed page is scaled as painted, so a fitted page scrolls as if it were still full width unless the scaled size is written back — which may well be why it was zoom in the first place. Worth stating the choice explicitly for whoever builds (4), rather than leaving the correction as the only route.

It is not only (4)

I framed the rect mismatch as something (4) would introduce. That is true of the anchor, but the mismatch itself is in 6.10.0 today: viewport_width and odr.setZoom() both apply the fit as body{zoom}, so any host that pins a zoom on WebKit is already in the split coordinate space, whether or not (4) ever lands. A host that only fits and scrolls will not notice. One that hit-tests will.

A host did trip over it

The iOS app's edit test taps the first editable run by taking getBoundingClientRect() and handing the centre to elementFromPoint(). With the page fitted through viewport_width it picks nothing; at that point × the zoom it picks the run. That is what the numbers in my comment above were taken from.

To be precise about what it does and does not show: the test simulates a tap by computing a point from a rect, which is exactly the mix that breaks. A real tap arrives in viewport coordinates and WebKit maps it itself, so nothing here demonstrates that tapping to edit breaks for a reader. It is evidence that host code mixing the two spaces is common enough to hit on the first document, not that the fit breaks editing.