Bug 255708

Summary: lvh/vh viewport units are incorrectly sized relative to the small viewport in SFSVC
Product: WebKit Reporter: Johannes Odland <johannes.odland>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Major CC: a_protyasha, augus.dupin, bramus, brett567, jcheung23, jensimmons, johannes.odland, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: Safari 16   
Hardware: iPhone / iPad   
OS: iOS 16   
See Also: https://bugs.webkit.org/show_bug.cgi?id=255852
Attachments:
Description Flags
Screenshot of David Bokans viewport unit test page
none
Screenshot of David Bokan’s test page
none
Test on iOS 18 beta 3
none
Test on iOS beta 3, SFSafariViewController, no UI.
none
Test on iOS beta 3, Safari, no UI.
none
Screenshot of test-page in Slack SFSafariViewController in iOS 26 none

Johannes Odland
Reported 2023-04-19 23:28:50 PDT
Created attachment 466000 [details] Screenshot of David Bokans viewport unit test page Viewport units inside SFSafariViewController are wrong. vh units and lvh units are sized relative to the small viewport. dvh units ends up being larger than lvh and vh units. This causes problems in webpages that use viewport units to size content. Steps to reproduce: Open David Bokan's viewport unit test page: https://bokand.github.io/demo/urlbarsize.html Expected result: The bars with height: 99vh and 99lvh should be sized relative to the large viewport (browser interface retracted). Actual result: The bars with height: 99vh and 99lvh are sized relative to the small viewport (browser interface expanded). 99dvh is larger than 99lvh.
Attachments
Screenshot of David Bokans viewport unit test page (657.20 KB, image/png)
2023-04-19 23:28 PDT, Johannes Odland 		no flags
Details
Screenshot of David Bokan’s test page (634.62 KB, image/png)
2024-07-15 21:10 PDT, Johannes Odland 		no flags
Details
Test on iOS 18 beta 3 (485.17 KB, image/png)
2024-07-16 11:12 PDT, Abrar Rahman Protyasha 		no flags
Details
Test on iOS beta 3, SFSafariViewController, no UI. (661.60 KB, image/jpeg)
2024-07-16 11:38 PDT, Abrar Rahman Protyasha 		no flags
Details
Test on iOS beta 3, Safari, no UI. (594.71 KB, image/jpeg)
2024-07-16 11:39 PDT, Abrar Rahman Protyasha 		no flags
Details
Screenshot of test-page in Slack SFSafariViewController in iOS 26 (613.26 KB, image/jpeg)
2025-10-15 22:46 PDT, Johannes Odland 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2023-04-21 12:44:26 PDT
<rdar://problem/108380836>
Johannes Odland
Comment 2 2023-06-07 22:27:21 PDT
Hi. I'm so exited for Safari 17. Do you know if there are any plans on improving support for viewport units in the SFSafariViewController?
Brett Donald
Comment 3 2023-09-05 18:10:46 PDT
See also https://bugs.webkit.org/show_bug.cgi?id=261185
Bruno Stasse
Comment 4 2024-07-15 04:15:41 PDT
This is quite problematic, as it makes both the `vh` and `lvh` unit unreliable on iOS. A fix would be much appreciated.
Brett Donald
Comment 5 2024-07-15 17:56:02 PDT
This bug is most likely a duplicate of 261185, which has been fixed and released in iOS 17.4 and iPadOS 17.4.
Abrar Rahman Protyasha
Comment 6 2024-07-15 18:16:48 PDT
@Bruno, I did make some improvements here with bug 261185. How much of this still reproduces for you?
Johannes Odland
Comment 7 2024-07-15 21:10:06 PDT
Created attachment 471891 [details] Screenshot of David Bokan’s test page From testing with the SFSafariViewController inside Slack, it seems like the viewport units are still wrong.
Abrar Rahman Protyasha
Comment 8 2024-07-16 11:12:21 PDT
Created attachment 471893 [details] Test on iOS 18 beta 3 @Johannes, which iOS version are you testing with? Here's what I see (with SFSafariViewController) on iOS 18 beta 3.
Bruno Stasse
Comment 9 2024-07-16 11:30:03 PDT
I have tested in iOS 17.5.1. I am not able to test in later versions at the moment. However, based on your screenshot @Abrar it looks like the bug is still present in iOS 18? We can see that when the browser UI is expanded `99svh` = `99vh` = `99lvh` = `739px`, which is incorrect. `vh` and `lvh` should be relative to the large viewport, that is the viewport with the browser UI collapsed. `svh` should be relative to the small viewport, that is the viewport with the browser UI expanded (as visible on your screenshot). As far as I can tell, on your screenshot `99svh` has the correct size, but `99vh` and `99lvh` should be bigger.
Abrar Rahman Protyasha
Comment 10 2024-07-16 11:38:46 PDT
Created attachment 471894 [details] Test on iOS beta 3, SFSafariViewController, no UI.
Abrar Rahman Protyasha
Comment 11 2024-07-16 11:39:13 PDT
Created attachment 471895 [details] Test on iOS beta 3, Safari, no UI.
Abrar Rahman Protyasha
Comment 12 2024-07-16 11:39:32 PDT
@Bruno, Thanks for the clarification. It looks like I was holding things wrong. I've attached named screenshots with the UI retracted (in both SFSafariViewController and in Safari) -- note the difference. We need to get SFSafariViewController up-to-par with Safari here.
Johannes Odland
Comment 13 2024-09-21 02:34:28 PDT
> @Johannes, which iOS version are you testing with? Here's what I see (with SFSafariViewController) on iOS 18 beta 3. @Abrar I just retested in iOS 18, and the issue is still there (as in your latest screenshots). 99vh=99lvh=99sv=659px while 99dvh=766px. Viewport units in IABs has been a big issue over the years. I hope these issues can be prioritized.
Johannes Odland
Comment 14 2025-10-15 22:46:48 PDT
Created attachment 477100 [details] Screenshot of test-page in Slack SFSafariViewController in iOS 26 I have tested the SFSafariViewController in a custom project in iOS 26. It works as expected both with barCollapsingEnabled true and false. With `barCollapsingEnabled:true` the bar collapses, and `dvh` is updated to match the available space. With `barCollapsingEnabled:false` the bar does not collapse, ans `dvh` is stable. However, the SFSafariViewController in the Slack app has an incorrect behavior. The bar does not collapse, but the `dvh` unit is scaled as if the bar is collapsing. As a result, the bar ends up on top of content on pages that adapt to the incorrect `dvh` value. Attaching a screenshot of the following test page in the slack app here: https://interop-2022-viewport.netlify.app/combined/viewport-units/ You can see that 100dvh = 100lvh, but the browser navigation bar is still visible on top. I am not sure if this is an issue with SFSafariViewController, or Slacks configuration.
Bramus
Comment 15 2025-10-16 02:27:31 PDT
@johannes: Did you check in iOS 26.1 beta 3 yet. Chrome had this issue in iOS 26 (https://issues.chromium.org/issues/446714234) but it’s now fixed in iOS 26.1 beta 3.
Johannes Odland
Comment 16 2025-10-16 22:27:39 PDT
@bramus: Haven't been able to check it out on iOS 26.1 beta 3 unfortunately.. Let's hope it's fixed there :)
Johannes Odland
Comment 17 2025-11-20 02:33:26 PST
@bramus: Just checked in Slack in iOS 26.1, and it is much better. There might be a small issue still. 100dvh is slightly larger than 100svh when browser chrome is expanded. (663px vs 657px).
Sam Sneddon [:gsnedders]
Comment 18 2025-12-05 14:17:45 PST
rdar://165941299
Note You need to log in before you can comment on or make changes to this bug.