Open theodore-earnin opened 3 years ago
I can confirm this bug. On ios safari & chrome don‘t show this behavior while firefox does…
Can confirm the same bug. Firefox on iOS is inconsistent with most browsers here, and are causing web compat issues. Most browsers stopped resizing vh since chrome stopped in 2016.
It is possible to use David Bokans test page to replicate the issue. This page tests the new viewport units lvh, dvh and svh as well.
The new units are supported in webkit since Safari 15.4, and can be supported in WKWebView from iOS 16 on I believe: https://developer.apple.com/documentation/webkit/wkwebview/3974127-setminimumviewportinset
This issue has been automatically marked as stale. Has the issue been fixed, or does it still require the community's attention? Please leave any comment to keep this issue opened. It will be closed automatically if no further update occurs in the next 30 days. Thank you for your contributions!
Steps to reproduce
or create a 0-width element with 100vh and log it's height on window resizing.
Expected behavior
For most other mobile browsers (as far as I can tell at least, tested on Safari/Chrome/Firefox on Android), this size remains constant even when the address and bottom bar hide on navigation, and only changes on actual window resizing/reorientation.
Actual behavior
The height of 100 vh (and document.documentElement.clientHeight) changes (increases) as the address bar shrinks and bottom bar hides after scrolling on the page. This makes it more difficult to build interoperable websites without having a consistent and easy-to-use way of determining the dimensions of the visible view on page load. What I'm experiencing doesn't seem like desired behavior, especially if other webpages rely on similar assumptions.
Device & build information
Notes
Attachments:
┆Issue is synchronized with this Jira Task