Open Radar

 
Summary:
The resize event is meant to be fired whenever the dimensions of the viewport change. Mobile Safari’s browser chrome does not instantly move in/out but rather slides, so for each step in that transition a resize event should be fired. Instead only one event is fired at the end of the transition.

Steps to Reproduce:
1) Open the attached resize_event.html file in Mobile Safari.
2) Scroll down, triggering the browser chrome to disappear.

Expected Results:
One resize event for each change in viewport dimensions. For example, if the browser chrome is 30px tall, then there should be 30 events fired, each one showing a viewport 1px taller as the browser chrome slides out.

Actual Results:
Only one resize event is fired.
In contrast, on OS X Safari when resizing the window multiple events are fired, one for each time the viewport size changes.

Notes:
It’s possible this is done as a performance measure, but it leads to really ugly UI issues for any sites relying on things like viewport units, `background-size: cover;`, etc.

In particular, what ends up happening is that since no resize events or layout recalculations are fired until the browser chrome has finished its transition, there’s a sudden flash of reflowed style, as opposed to an elegant transition of the page in coordination with the browser’s chrome.

A fuller example of this issue’s impact on user experience can be found at my site (http://karanlyons.com). Just simply scroll down a bit in Mobile Safari and watch as the hero image suddenly resizes as the chrome finishes sliding out.

A current workaround is to target Mobile Safari specifically and freeze the layout of anything relying on viewport units and the like assuming the chrome is always visible, but while this solves the flash of reflowed style, it still provides a less than ideal UI experience for the user.

Configuration:
Mobile Safari on iPhone 6

Attachments:
'resize_event.html’ (http://karanlyons.com/resize_event.html)