254868 2023-04-01 07:09:29 -0700 Incorrect height values when viewport-fit=cover is set for installed web apps 2025-11-18 11:04:27 -0800 1 1 1 Unclassified WebKit Layout and Rendering Safari 16 Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=255852 https://bugs.webkit.org/show_bug.cgi?id=210009 InRadar P2 Normal --- 1 ik webkit-unassigned bfulgham jcheung23 matan.hershberg simon.fraser webkit-bug-importer wenson_hsieh zalan oldest_to_newest 1945954 0 ik 2023-04-01 07:09:29 -0700 Several css values and javascript APIs report incorrect height values for installed web apps when <meta name="content"> has "viewport-fit=cover". The following values report heights of the available space *minus* safe-area-inset: - 100svh - -webkit-fill-available - visualViewport.height Note: It's very likely that this list is not complete, it's just what I ran into. The workaround for CSS is fairly easy (but should not be needed): ```css /* Use svh (with fallback for older versions) in regular safari: */ html, body { min-height: -webkit-fill-available; min-height: 100svh; } /* Switch to 'vh' when in standalone: */ @media all and (display-mode: standalone) { html, body { min-height: 100svh; } } ``` I'm not sure if there is a workaround for visualViewport.height though... Related: https://bugs.webkit.org/show_bug.cgi?id=237961 1945972 1 webkit-bug-importer 2023-04-01 11:15:18 -0700 <rdar://problem/107512425> 1945975 2 ik 2023-04-01 11:21:50 -0700 Ah just now noticed a typo in my example/workaround code. For standalone display-mode, it should use 'vh' units as that does include safe-area-inset: ``` /* Switch to 'vh' when in standalone: */ @media all and (display-mode: standalone) { html, body { min-height: 100vh; /* <== should be 'vh', not 'svh' } } ``` 1946016 3 ik 2023-04-02 01:27:45 -0700 Note: WebKit currently has a bug where safe-area-inset-bottom doesn't update then the keyboard is visible (https://bugs.webkit.org/show_bug.cgi?id=217754), so please make sure that the height reported: - does include safe-area-inset-* when the keyboard is NOT visible - does NOT include safe-area-inset-bottom when the keyboard IS visible - there may be other cases where safe-area-inset should NOT be included Thanks! 2108103 4 ik 2025-04-02 00:04:48 -0700 This is still an issue on iOS 18.3.1 (haven't tested with 18.4 yet). 2111768 5 ik 2025-04-18 01:46:19 -0700 I think `inset` is affected as well when in standalone and viewport-fit=cover. I expect the following element to stick to the bottom of the display ```css .stick-to-bottom { position: absolute; inset: auto 0 0; } ``` But the element sits above the bottom (haven't checked the exact offset, but looks to be the safe-area-insets top and bottom from eyeballing it). Switching to `position: fixed;` fixes it (which is funny, because it says `fixed` :P)