NEW 279998
REGRESSION (iOS 18): svh and lvh are incorrect on iOS in third party browsers
https://bugs.webkit.org/show_bug.cgi?id=279998
Summary REGRESSION (iOS 18): svh and lvh are incorrect on iOS in third party browsers
Jesper van den Ende
Reported 2024-09-19 11:26:08 PDT
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.
Attachments
screen recording of Safari vs Chrome (5.04 MB, video/quicktime)
2024-09-30 04:38 PDT, Jesper van den Ende
no flags
A screen recording of Safari vs. Chrome - working fine (7.20 MB, video/mp4)
2024-09-30 05:19 PDT, Michał Gołębiowski-Owczarek
no flags
Radar WebKit Bug Importer
Comment 1 2024-09-20 17:01:29 PDT
Michał Gołębiowski-Owczarek
Comment 2 2024-09-29 11:10:44 PDT
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?
ik
Comment 3 2024-09-30 00:24:22 PDT
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
Comment 4 2024-09-30 04:12:38 PDT
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.
ik
Comment 5 2024-09-30 04:22:21 PDT
> 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
Comment 6 2024-09-30 04:38:32 PDT
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
Comment 7 2024-09-30 05:15:56 PDT
(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
Comment 8 2024-09-30 05:19:31 PDT
Created attachment 472736 [details] A screen recording of Safari vs. Chrome - working fine Here’s my screencast where it works.
Jesper van den Ende
Comment 9 2024-09-30 06:50:31 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.