Issue metadata
Sign in to add a comment
|
100 vh units in Chrome on Android is extended beyond viewport in the browser breaking Progressive Web Apps in browser mode
Reported by
enjik...@gmail.com,
May 19 2018
|
||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: 1. Imagine a simple app view with header, main content area and footer. 2. This would be implemented with flexbox today using 100 vh as max height for the wrapper. (See demo.html for a typical PWA layout structure like this) What is the expected behavior? The footer is visible when visiting the app in the mobile browser. What went wrong? The footer is outside the viewport - even though we've capped the app to not be outside 100 percent of the view port height in CSS. Did this work before? Yes 55 Does this work in other browsers? N/A Chrome version: 66.0.3359.158 Channel: stable OS Version: 8.1.0 Flash Version: no The footer becomes visible when the PWA is saved to home screen and opened from there. This issue seems to be because of this stupid idea where the URL bar is pushing the content down without the browser appropriating the view port height. https://developers.google.com/web/updates/2016/12/url-bar-resizing Just because the Chrome on Android-app employs a conditionally hidden URL bar in its UI does not mean the complexity of handling the bugs it gives the Chrome on Android-team should be passed over to us web developers by breaking the reliability of the vh unit. Would love to see this fixed as soon as possible.
,
May 21 2018
Tested the issue in Android and able to reproduce the issue. Steps Followed: 1. Launch Chrome. 2. Navigate to attached html 3. Observed the footer is outside the viewport Chrome versions tested: 66.0.3359.158(Stable), 68.0.3434.0(Canary) OS: Android 8.1.0 Android Devices: Pixel 2 Using the per-revision bisect providing the bisect results, Good Build - 56.0.2909.0 Bad Build - 56.0.2910.0 CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/56.0.2909.0..56.0.2910.0?pretty=fuller&n=10000 Suspecting https://chromium.googlesource.com/chromium/src/+/1bddf0ae1615f5c67ca034d7e08dfdb1ea5846c4 @wangxianzhu: Could you please take a look at this and help Unable to provide tool bisect info as builds are not invoking using bisect script. Please navigate to below link for log's and video-- go/chrome-androidlogs/844848 Thanks!
,
May 21 2018
I think this is an outcome of "Top Controls don't resize initial containing block and vh units" (https://chromium.googlesource.com/chromium/src/+/7f8de7508a3e8098ed174c59daa5b068808382f8). Assigning to bolan@ for confirmation.
,
May 24 2018
This is WAI and interoperable with Safari so we're not going to change anything here unilaterally.
Prior to the change, the page would reflow with each change of scrolling direction which is jarring to users. This may seem correct in the given demo page but it makes vh units basically unusable on mobile otherwise (e.g. images or fonts sized with vh).
You can achieve the desired effect with:
<style>
body, html, .app {
height: 100%;
}
Having 100vh be viewport filling when the URL bar is showing (matching `height:100%` style) would be more consistent and work in cases like the example. However, Safari made this choice long ago and we decided interop is more important to web devs.
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by sandeepkumars@chromium.org
, May 21 2018