Bug 258663 – Initial scale of a page is not respected when both initial scale and viewport width are set

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[juwagn]

Created attachment 466863 [details]
viewport bug in meta tag on iOS 16.5.1 Safari

Hello,

<meta> tag name="viewport" and as example content="width=600***** stopped to work correctly after upgrading from iOS 16.1.1 to 16.5.1

Let's assume you have physic screen size on iPad 810x1080 and you want to set viewport width to 600px, then issue will occur in landscape and portrait mode, the browser reports then not expected 600px in width, but depending on orientation physic width.

If you set viewport width to 900px then issue will occur only in landscape mode since physic screen width in portrait mode is 810 and that is lower value than 900px, and issue won't occur, but in landscape mode physic size 1080 is higher than 900px and issue will occur, reports then unexpected width.

If you set as viewport width 1200 or any higher value then issue won't occur for both orientations, since 1200px is higher value than physic screen size in both - height and width (in the example 810x1080). 
Do you have any idea which degradation occured in iOS 16.5.1 that makes such issue?

Attached file 
viewport600.html with width=600
if you open it on Safari iOS 16.5.1 then you will notice the smallest screen size is then the width of your physic screen depending on orientation. 
If you change that value from 600 as example to width=1400 then it will work fine in both orientations.
Actually it is blocker since many users experienced wrong behavior by prefering viewport 600 in width on their devices.

On Android devices with common browsers such error doesn't occur.
Thank you in advance!

Sincerely yours.

[juwagn]

Just in addition, in example i have set initial-scale=1 
but usually i set minimum-scale and initial-scale instead fixed dynamically and as their value divided physic screen size by viewport width

lets assume physic screen width for wished viewport width 600
landscape 1080 / 600 = 1.8
portrait 810 / 600 = 1.35
<meta name="viewport" content="width=600, user-scalable=yes, initial-scale=1.8, minimum-scale=1.8" />
or 
<meta name="viewport" content="width=600, user-scalable=yes, initial-scale=1.35, minimum-scale=1.35" />
in such case it will cause issue on iOS 6.5.1 and work fine on iOS 6.1.1

Also it seems when minimum-scale/initial-scale is lesser than 1, like 0.79 then OK, if higher values than 1, like 1.35 then issue occurs.

[Radar WebKit Bug Importer]

<rdar://problem/111515914>

[juwagn]

Created attachment 466898 [details]
New example for testing on iOS 16.5.1/16.1.1/15.7.7 and Android devices

New example for testing on iOS 16.5.1/16.1.1/15.7.7 and Android devices

[juwagn]

Hello, just uploaded new example to test.


It shows error happening on iOS 16.5.1
when at same time iOS 16.1.1 and 15.7.7 are OK, same OK as Android devices, so regression is since iOS 16.5.1 in Safari.

Example allows to set meta width on the fly and in orientation changing, 
you can switch from 600 to 1400 with buttons.

PS: in my previous message i was wrong that error doesn't occur on higher width than device with but it occurs really with all values on iOS 16.5.1.

[Abrar Rahman Protyasha]

Retitled the bug to better represent the root cause.

[Abrar Rahman Protyasha]

Pull request: https://github.com/WebKit/WebKit/pull/15552

[juwagn]

Hello Abrar Rahman Protyasha,

on github you wrote that so called scale clamping gets performed on every page and that it isn't clear why the initial scale is not being respected, even when a developer may have had a valid use-case.
But my personal question is, when this scale clamping bug was introduced exactly, was it possible to track it down?
Just would like to be sure that my second test case attached here on the top is passing your new workaround!?
https://bug-258663-attachments.webkit.org/attachment.cgi?id=466898
Thank you!

Sincerely yours.

[Abrar Rahman Protyasha]

The behavior change occurred in https://webkit.org/b/247636, and the proposed fix here works for both test cases.

[EWS]

Committed 265804@main (524f1bcc6830): <https://commits.webkit.org/265804@main>

Reviewed commits have been landed. Closing PR #15552 and removing active labels.