Bug 319180 – WKWebView content renders at device/980 scale after loading in a compact sheet

• Status: NEW
• Component: New Bugs

Created attachment 480525 [details]
Complete standalone reproducer, automated runner, classifier tests, controls, measurements, and screenshots (commit 7c47788)

On the iOS 26.3.1 Simulator runtime, a fresh nonopaque `WKWebView` presented in a compact `UISheetPresentationController` can finish a local device-width load in an internally inconsistent visual state. The DOM viewport and every public zoom value report the correct device width / 1.0, while the visible document and public `UIScrollView.contentSize.width` are scaled down by approximately `deviceWidth / 980` (for example, `402 -> 164.6667`).

This is intermittent but reproducible without networking, third-party code, application CSS, private API, or injected transforms.

## Steps to reproduce

1. Clone the standalone sample:
   https://github.com/rameerez/WKWebViewSheetViewportRepro
2. Boot an iOS 26.3.1 Simulator.
3. Run `scripts/run_repro.sh [SIMULATOR_UDID]`.
4. If the first 30-iteration pass is healthy, rerun it to exercise the race.

The runner creates a fresh web view each iteration, applies:

```swift
webView.isOpaque = false
webView.backgroundColor = .systemBackground
```

It constrains the web view to a plain controller, presents that controller at one custom 300-point sheet detent, and calls `loadHTMLString` with a tiny local device-width document after presentation completes. Healthy sheets are dismissed and the sequence repeats. A qualifying failure stops the run and leaves the sheet visible.

## Expected result

The yellow `width: 100%` document fills the 390- or 402-point sheet width. DOM, public WebKit geometry, and visible rendering agree.

## Actual result

The document is visibly rendered at about 40% of the sheet width and remains in that state. Two final independent runs produced:

| Device | Iteration | web-view width | public content width | DOM inner/client/visual | zoom/min/max/page/visual |
| --- | ---: | ---: | ---: | ---: | ---: |
| iPhone 17 Pro | 10 | 402 | 164.6667 | 402 / 402 / 402 | 1 / 1 / 1 / 1 / 1 |
| iPhone 16e | 11 | 390 | 155 | 390 / 390 / 390 | 1 / 1 / 1 / 1 / 1 |

The published checkout also reproduced `402 -> 164.6667` at iteration 3 in its final clean one-command run. The bad public content widths closely match the device-to-980 scale when expressed as a content-width / web-view-width ratio. The state persists through delayed 100 ms, 500 ms, and 750 ms probes.

## Reduction and controls

- No navigation controller, detent transition, network load, framework, representative app markup, form, sticky/fixed content, or private API is required.
- `isOpaque = false` alone completed 100 iterations without a qualifying collapse.
- `backgroundColor = .systemBackground` alone completed 100 iterations without a qualifying collapse on each of two simulators.
- The pair reproduced in both final clean runs.
- Loading before presentation, reusing one initialized web view, full-screen presentation, and one large detent each completed 50–100 cycle controls without a qualifying collapse.
- An iOS 18.3 Simulator control completed 100 iterations without a qualifying collapse.

Raw JSONL public-API measurements, strict classifier tests, screenshots, and all control summaries are included in the repository under `evidence/`. Application-level prevention/recovery guidance is intentionally kept separate in `MITIGATION.md`; it does not change the expected WebKit behavior described here.

## Environment

- Host: macOS 15.7.3 (24G419), Apple M1 Max
- Xcode 26.3 (17C529)
- Built with iOS 26.2 Simulator SDK
- Reproduced on iOS 26.3.1 Simulator runtime 23D8133
- Runtime WebKit bundle 8623.2.7.10.4
- Not yet reproduced on a physical device
- Apple’s current public iOS release is 26.5.2, but that runtime is not
  available in the installed Xcode 26.3 environment and has not yet been
  tested

## Related reports

- Bug 262207 also concerns an approximately 980-wide fallback, but there the DOM viewport itself reports the wrong width. Here DOM inner/client/visual widths are already correct and only visible/public native content geometry is stale: https://bugs.webkit.org/show_bug.cgi?id=262207
- Related WKWebView resize reports:
  https://bugs.webkit.org/show_bug.cgi?id=170595 and
  https://bugs.webkit.org/show_bug.cgi?id=267545
- Another intermittent WKWebView viewport-timing report:
  https://bugs.webkit.org/show_bug.cgi?id=191872

I am happy to collect additional diagnostics or test a candidate build.

Created attachment 480526 [details]
Failure screenshot showing stale narrow WKWebView rendering at 402 → 164.6667 points

[Radar WebKit Bug Importer]

<rdar://problem/182625030>