Bug 261185 – [iOS] `svh`/`dvh` units are unexpectedly equal when Safari tab bar is not visible

• Component: CSS
• Status: RESOLVED FIXED

[Brett Donald]

SUMMARY

Mobile Safari is not distinguishing between the CSS units svh and dvh. These units should yield different dimensions in certain circumstances, however, instead they are yielding the same dimensions in all circumstances.

Safari support for these units was announced in the WebKit blog around a year ago. These units are described in the specification CSS Values and Units Module Level 4.

TEST PAGE TO ILLUSTRATE THE BUG

https://donald.au/bugs/svh/test.html

This test page contains four elements, each of which is sized using a different unit. The first element is sized as 100vh, the second as 100svh, the third as 100dvh and the fourth as 100lvh.

EXPECTED BEHAVIOUR

As the toolbars are collapsed and expanded, the only element which should change size is the one sized with dvh units (the lime coloured element). The other three elements should maintain a fixed size.

When viewing the page in the small viewport (toolbars expanded), the elements sized with svh and dvh should both exactly fit the viewport, and the element sized with lvh should be larger than the viewport.

When viewing the page in the large viewport (toolbars collapsed), the elements sized with dvh and lvh should both exactly fit the viewport, and the element sized with svh should be smaller than the viewport.

To put it another way, the yellow element should be short, the pink element should be long, and the lime element should switch between short and long.

ACTUAL BEHAVIOUR

As the toolbars are collapsed and expanded (using the Hide Toolbar menu option), both the elements sized with svh and dvh change their size. Interestingly, the yellow element changes size immediately and the lime element adjusts a split second later. However, point here is that the yellow element should not be changing its size at all.

ILLUSTRATIONS

A mockup illustration of the expected behaviour, and a screenshot video of the actual behaviour are available at the link below. Captured on an iPhone running iOS 16.4.1.

https://donald.au/bugs/svh/

[Brett Donald]

Created attachment 467561 [details]
Mockup illustration of expected behaviour of the test page

[Brett Donald]

Created attachment 467562 [details]
Screenshot video of actual behaviour of the test page

[Johannes Odland]

See also David Bokans test page here: https://bokand.github.io/demo/urlbarsize.html

This might be the expected behavior. 

When the toolbar is automatically hidden due to scrolling, only the dvh sized bar changes. The svh sized bar stays unaffected. This is as expected. 

When you press the “Hide toolbar” option however, you effectively turn off the automatic show/hide functionality. As there no longer is a toolbar that will automatically cover parts of the viewport the small viewport can be interpreted to be the same as the large viewport, similar to desktop browsers.

I’m not sure what the correct interpretation should be here. It would be interesting to hear from the implementers. 

Do you have a specific use case where it’s important that the small viewport stays unaffected when the user disables the toolbar altogether?

[Brett Donald]

Selecting "hide toolbar" is not a permanent change though. As soon as you click on the mini toolbar, the large toolbar reappears.

I don't have a specific use case, but I'm imagining a scenario where I have a background image covering the small viewport with some overlay text in the centre of it. I don't want that text to reposition itself to the centre of the large viewport when the user hides the toolbar, I want to it to stay put. There would be no way to achieve that unless svh behaves the way I expect it to, as described in this bug report.

[Radar WebKit Bug Importer]

<rdar://problem/115085360>

[Johannes Skuterud]

If it is intentional, I must say it’s all very confusing.

I know for a fact that if you swiped on the tab bar in previous versions, it would minimize but reappear when the user scrolled.

So why is it different now?

I wish there was a way to always show the tab bar using a meta tag, and avoid all the headaches with the dynamic viewport altogether.

If it is intended that 100svh should change value when hiding the tab bar(not by scrolling), I would at least expect the web content positioned sticky or fixed to “stick” to the tab bar during the animation that hides and shows it.

I find it ugly that, for instance, the ::backdrop element does not animate with the tab bar when it animates.

I ask, what would the user expect when hiding it?
  
  1. For the background image to resize? No.
  2. For the underlaying, hidden content to suddenly show? No.
  3. For the fixed modal to change height after the tab bar animates. No.

Ughh…

[Abrar Rahman Protyasha]

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

[Abrar Rahman Protyasha]

Brett, thanks for the bug report. I agree that this is unexpected behavior. Our small viewport units are not spec compliant currently because we allow clients to override layout parameters without enforcing collection of the minimum unobscured layout size _assuming_ all dynamic UI elements (like the Safari tab bar) are visible. This needs to be changed with a combination of WebKit changes and client-side adoption, with the former being captured by the PR I just posted.

[EWS]

Committed 270516@main (cc2d17a95691): <https://commits.webkit.org/270516@main>

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

[WebKit Commit Bot]

Re-opened since this is blocked by bug 264613

[Abrar Rahman Protyasha]

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

[EWS]

Committed 270652@main (43148740f3be): <https://commits.webkit.org/270652@main>

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