Bug 279998 – REGRESSION (iOS 18): svh and lvh are incorrect on iOS in third party browsers

• Component: CSS
• Status: RESOLVED INVALID

[Jesper van den Ende]

Since updating to iOS 18, dynamic viewport units are displaying incorrectly.

To reproduce, visit https://10svh-10dvh-10lvh.glitch.me/ in a third party browser on iOS 18.
Observe that the three green bars are all the same height.
The expected result should be that svh and lvh have a different size and don't resize when scrolling.
In safari it still seems to work as expected, only third party browsers are affected.

[Radar WebKit Bug Importer]

<rdar://problem/136394949>

[Michał Gołębiowski-Owczarek]

I run the test case on Chrome on iOS 18 and it works as expected: lvh is greater than svh and dvh switches between both when scrolling up & down. Am I missing anything?

I can reproduce this on Firefox 130.1 on iPadOS 18.0 (iPad Mini, 5th gen). Both svh and lvh are the same height.

Chrome seems to behave correctly (as in, svh and lvh are different heights, and dvh updates to match the 'current' state).

I will say that the difference between svh and lvh doesn't seem right to me. It's like 8px but the address bar seems collapses more than that? I'll try and find some time to check that and create a separate ticket if needed.

Thanks!

[Jesper van den Ende]

The difference is indeed only 8px, this demo uses '10dvh' instead of '100dvh' to make sure the bars are not partially hidden behind the address bar.

I can still replicate this in Chrome for some reason though.

> this demo uses '10dvh' instead of '100dvh'

Ah right, so it's only a percentage of the total difference. I'm gonna grab some coffee :))

> I can still replicate this in Chrome for some reason though.

@Michal did you (also) test on a EU version of iOS? (seems unlikely this has something to with it, but you never know...)

[Jesper van den Ende]

Created attachment 472733 [details]
screen recording of Safari vs Chrome

Fwiw, here's a screen recording of the behaviour in Safari and Chrome. This was Chrome 129.0.6668.69 and iOS 18.0 (22A3354)

[Michał Gołębiowski-Owczarek]

(In reply to ik from comment #5)
> @Michal did you (also) test on a EU version of iOS? (seems unlikely this has
> something to with it, but you never know...)

I'm in Poland, so yes, in EU. Version 129.0.6668.69.

[Michał Gołębiowski-Owczarek]

Created attachment 472736 [details]
A screen recording of Safari vs. Chrome - working fine

Here’s my screencast where it works.

[Jesper van den Ende]

It seems like this is caused by the 'Fullscreen Smooth Scrolling' flag.
If I enable it here: chrome://flags/#fullscreen-viewport-adjustment-experiment
I'm no longer able to reproduce it and if I disable it I am.
I suppose of you leave it set to default it will run an A/B test so the results are random.
I'm not aware of any similar flag for Firefox.

[Lily Spiniolas]

svh and lvh units can be established by third party browsers via WebKit API 'setMinimumViewportInset:maximumViewportInset:' which determines the minimum and maximum viewport sizes by subtracting each one from the size of the view. Neither browsers use this API (at least last I checked), though the units appear correctly in Chrome when chrome://flags/#fullscreen-viewport-adjustment-experiment is enabled because they use WebKit SPI '_overrideLayoutParametersWithMinimumLayoutSize:minimumUnobscuredSizeOverride:maximumUnobscuredSizeOverride:'. This is not a regression, the API just needs to be adopted.