Safari returns 0 for --safe-area-inset-bottom when the toolbar is hidden

Question

Created Sep ’22

Replies 2

Boosts 2

Views 3k

Participants 3

Safari is returning 0 for --safe-area-inset-bottom when I use getComptutedStyle method on Iphones running on ios +15 both on portrait and landscape mode when the toolbar is hidden.

I can guess that it's desired when the address bar is on the bottom and is hidden, however, is it supposed to return 0 when the address bar is set to be on the top (like on the ios versions -15) and the toolbar is hidden? Is it intended or an overlook from Safari?

Comparison between versions:

Safari ios14 hidden top toolbar portrait --safe-area-inset-bottom : 34, Safari ios14 hidden top toolbar landscape --safe-area-inset-bottom: 21

Safari ios 15+ hidden top toolbar portrait --safe-area-inset-bottom : 0, Safari ios 15+ hidden top toolbar landscape --safe-area-inset-bottom: 0

Boost

Answer 1

PaulHatesUsernames OP

Jan ’23

I've got this exact same issue; I use the safe-area-inset values to make sure the bottom long white line doesn't overlap content that the user must always see. The bar doesn't disappear because the player needs to be interacting with the screen. In ios15+16 the safe-area-inset-bottom value is 21px. If I hide the address bar, this value becomes 0, and the white bar is blocking our content. If I tap the address bar to unhide, the page occasionally shifts behind the address bar until I scrollTo(0,1) and then in a timeout of at least 50ms scrollTo(0,0). The browser seems to be unaware that the page has scrolled up by 21 pixels, even checking the positioning.

One of a handful of weird positioning / visibility issues in Safari at the moment :)

1

Answer 2

chebread OP

Aug ’23

Still having this issue on iOS16.

First I set padding-bottom: 21px; as a solution. I'm trying to use , but this also seems strange if it's not an ios device.

Has this issue been fixed now in ios16?

0