Bug 267545 – Window size incorrect in resize event in WKWebView only

• Status: NEW
• Component: Layout and Rendering

[Ashley Gullen]

In WKWebView only, the reported window innerWidth/innerHeight is sometimes incorrect in a "resize" event.

Minimal repro: https://downloads.scirra.com/labs/bugs/windowsizetest.html

Steps to reproduce:

1. Load the URL on an iOS device in a WKWebView. This can be done with a test app like ExpoFP WKWebViewer, a framework like Cordova, or a browser like Chrome for iOS which is implemented using WKWebView, all of which reproduce the issue. Presumably Apple have their own internal WKWebView tester too.
2. Start in portrait orientation. Observe the logged messages.
3. Change to landscape orientation. Observe the logged messages.

Observed result:

The logged size in a window "resize" event is usually incorrect in this case. It has the wrong size, but the correct size is silently returned by the window innerWidth/innerHeight values shortly after the event. For example it logs the following:

window 'resize' event: size 428 x 372 ... @ 6.1s
timer: size 926 x 351 ... @ 10s

This demonstrates that the "resize" event fired with the wrong size, and later when a timer fires to retrieve the size, it is then returning the correct size, but no "resize" event was fired since the correct size started being returned.

This does not reproduce in the Safari browser. It only reproduces in WKWebView. It is worth noting as well that the Safari browser only fires one "resize" event for the change of orientation, but WKWebView redundantly fires two (both with the wrong size).

Reproduced on an iPhone 12 Pro Max with iOS 17.2.1. It can cause content to become unusable due to sizing incorrectly. Note that as this appears to be a long-standing bug affecting only non-Safari browsers on iOS, it may have regulatory significance.

[Radar WebKit Bug Importer]

<rdar://problem/121377215>