100vh includes size of Android status bar when using Add to Homescreen
Reported by
gerardos...@gmail.com,
Feb 4 2017
|
||||||||
Issue descriptionDevice name: Pixel XL From "Settings > About Chrome" Application version: Chrome 56.0.2924.87 Operating system: Nougat 7.1.2 URLs (if applicable): http://dobleu.xyz Steps to reproduce: (1) set div height to 100vh (2) scroll and you'll see div is larger than viewport now, it was working fine before. Expected result: The div should be the size of the viewport. No less, no more. Actual result: The div goes larger now, apparently the discrepancy is equal to the size of the Chrome App Bar. If you add the Web App to the homescreen on Android, tho, where there's no App Bar, it seems like there's still an issue, since it looks like 100vh is still larger than the actual viewport. I believe the discrepancy is equal to the size of the Android Status Bar in this case. This occurs only on Android, since Chrome on desktop is working just fine. For comparison purposes I attached an image showing how it was looking before, when it was working as expected, and how it is now, side by side, the content moved since the div is larger and it's not vertically centered anymore.
,
Feb 6 2017
,
Feb 7 2017
Intended behavior change, see https://github.com/bokand/URLBarSizing for the rationale.
,
Feb 23 2017
In the second case mentioned (the one where the app has been added to the home screen, and we have only the Android top bar[1] on top) it seems like 100vh equals to the total screen size. Is this correct? I was under the impression that the Android top bar was not to be considered part of the viewport as scrolling does not make it disappear, but one has to explicitly request fullscreen and the user has to grant it (via requestFullscreen), so all the problems described in https://github.com/bokand/URLBarSizing do not seem to apply to this case. [1] Where battery status, notifications etc appear: I might have used the incorrect term here
,
Feb 23 2017
Yes, it appears you're correct. Chrome currently seems to include the status bar when it shouldn't. This is a bug.
,
Feb 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/85fff922d53f16ad66d8d39cb066cbcda1640052 commit 85fff922d53f16ad66d8d39cb066cbcda1640052 Author: bokan <bokan@chromium.org> Date: Fri Feb 24 23:25:24 2017 vh units shouldn't add controls height when controls are locked to hidden. Since the initial containing block is now fixed to be the size as if the browser controls are always shown -- and we want 100vh to appear as if the viewport is always hidden -- we add the browser controls height to the layout height used for viewport units. One exception to this when the browser controls are locked in a hidden state. In that case, the ICB is actually set to fill the full viewport. In that case adding the controls height actually makes 100vh taller than the viewport. This patch avoids adding the controls height when controls are locked hidden. BUG= 688738 Review-Url: https://codereview.chromium.org/2716453004 Cr-Commit-Position: refs/heads/master@{#452991} [modify] https://crrev.com/85fff922d53f16ad66d8d39cb066cbcda1640052/third_party/WebKit/Source/core/frame/FrameView.cpp [modify] https://crrev.com/85fff922d53f16ad66d8d39cb066cbcda1640052/third_party/WebKit/Source/web/tests/BrowserControlsTest.cpp
,
Feb 27 2017
This should be merged to 57.
,
Feb 27 2017
Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions. Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 27 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e2457ff0890ac0eaf34c7ea0312f3e9d30f866a6 commit e2457ff0890ac0eaf34c7ea0312f3e9d30f866a6 Author: bokan <bokan@chromium.org> Date: Mon Feb 27 14:07:41 2017 vh units shouldn't add controls height when controls are locked to hidden. Since the initial containing block is now fixed to be the size as if the browser controls are always shown -- and we want 100vh to appear as if the viewport is always hidden -- we add the browser controls height to the layout height used for viewport units. One exception to this when the browser controls are locked in a hidden state. In that case, the ICB is actually set to fill the full viewport. In that case adding the controls height actually makes 100vh taller than the viewport. This patch avoids adding the controls height when controls are locked hidden. BUG= 688738 Review-Url: https://codereview.chromium.org/2716453004 Cr-Commit-Position: refs/heads/master@{#452991} (cherry picked from commit 85fff922d53f16ad66d8d39cb066cbcda1640052) Review-Url: https://codereview.chromium.org/2720743002 . Cr-Commit-Position: refs/branch-heads/2987@{#694} Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943} [modify] https://crrev.com/e2457ff0890ac0eaf34c7ea0312f3e9d30f866a6/third_party/WebKit/Source/core/frame/FrameView.cpp [modify] https://crrev.com/e2457ff0890ac0eaf34c7ea0312f3e9d30f866a6/third_party/WebKit/Source/web/tests/BrowserControlsTest.cpp
,
Feb 27 2017
,
Mar 24 2017
,
Aug 18 2017
Issue 700395 has been merged into this issue. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by rsgav...@chromium.org
, Feb 6 2017Status: Assigned (was: Unconfirmed)