Bug 255708 – lvh/vh viewport units are incorrectly sized relative to the small viewport in SFSVC

• Status: NEW
• Component: CSS

[Johannes Odland]

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.

[Radar WebKit Bug Importer]

<rdar://problem/108380836>

[Johannes Odland]

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]

See also https://bugs.webkit.org/show_bug.cgi?id=261185

[Bruno Stasse]

This is quite problematic, as it makes both the `vh` and `lvh` unit unreliable on iOS. A fix would be much appreciated.

[Brett Donald]

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]

@Bruno, I did make some improvements here with bug 261185. How much of this still reproduces for you?

[Johannes Odland]

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]

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]

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]

Created attachment 471894 [details]
Test on iOS beta 3, SFSafariViewController, no UI.

[Abrar Rahman Protyasha]

Created attachment 471895 [details]
Test on iOS beta 3, Safari, no UI.

[Abrar Rahman Protyasha]

@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]

> @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]

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]

@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]

@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]

@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).