Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 428132 Top Controls change layout viewport height
Starred by 80 users Reported by b...@benknight.me, Oct 28 2014 Back to list
Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug

Blocked on:
issue 565930
issue 586872



Sign in to add a comment
Example URL:
http://f.cl.ly/items/0439123e3w1L3O2w1e3Z/100vh.html

Steps to reproduce the problem:
1. Set a an elements style to `height: 100vh` in CSS.

What is the expected behavior?
The document maintains the same dimensions as you scroll.

What went wrong?
Observe that as Chrome for Android's address bar goes off screen, vh units are recomputed and therefore the vertical position of items on the screen suddenly changed.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 38.0.2125.102  Channel: stable
OS Version: 4.4.4
Flash Version: 

While it makes sense that the viewport has indeed become taller, the vh unit is not of much use to authors if it changes during scrolling.
 
Comment 1 by tkent@chromium.org, Oct 31 2014
Labels: -Cr-Content Cr-Blink-CSS
Comment 2 by Deleted ...@, Nov 30 2014
I Actually noticed this happening as well, you ask for 100vh and when you scroll the navigator bar off the screen, it sort of thinks now there is more screen height so all vh units are recalculated, making a popping like effect
Comment 3 by timloh@chromium.org, Nov 30 2014
What's the desired behaviour here? I can't think of anything that lets us handle the navigator bar appearing/disappearing nicely.
Comment 4 by b...@benknight.me, Nov 30 2014
The desired behavior would be that dimensions based on the viewport unit `vh` don't change when the user is scrolling, otherwise I don't see what use it is to developers because if `vh` is recomputed during scrolling, you're going to have a sudden recalculation of anything that's set based on it, which is a bad user experience.  For me, the biggest use case for `vh` is setting a container to a height of 100vh so it spans the whole height of the screen, such as a large photograph-style header.
Comment 5 by timloh@chromium.org, Nov 30 2014
So if we load a page with the navigator bar, and then the user scrolls so that the bar disappears, you'd want 100vh to still refer to the reduced size? This doesn't seem any better, since now 100vh doesn't refer to the whole screen.
Comment 6 by b...@benknight.me, Dec 1 2014
I agree.  I think quite literally the viewport height is growing therefore the current behavior is arguably correct.  Still, the kind of scenario I've illustrated in the example URL I think is likely to cause developers frustration and make `vh` essentially unusable.  A recalculation of dimensions is expected during a change in device orientation or during a window resizing in a desktop context, which both cause the viewport dimensions to change, but during scrolling this is a bit different.  Authors would not expect the viewport to change size during scrolling.  Perhaps coupling document dimensions and/or font sizes to the viewport is bad practice to begin with.
I think the viewport should be calculated to begin with without the address bar. It should be considered to be floating on top, as it does any time you use the app switcher to come back to a tab that has been scrolled. It floats on top, then disappears, without affecting the viewport. This would be problematic for new page loads where scrollY == 0, the page has not finished loading, so the address bar remains, with content stuck beneath it. For this I would think some kind of faux-margin might work to push the viewport down under the address bar, retracting the address bar and the margin on teh viewport when the page finishes. Before the page has finished, the user can simply scroll down (also retracting the margin, but not the address bar) to pull the viewport into full view (though maybe still covered by the address bar), and scroll back up, only revealing the covered portion AFTER you reach scrollY == 0, but in one continuous motion.
Comment 8 by gavin.el...@me.com, Dec 29 2014
One way to fix this is to set the viewport meta tag to the device height, e.g. 
<meta content="width=device-width, height=device-height, initial-scale=1" name="viewport">
Comment 9 by b...@benknight.me, Dec 30 2014
Gavin, I checked and I'm sorry to say that didn't solve the problem described here.
Comment 10 by asan...@gmail.com, Feb 14 2015
I also suffer this! And the proposed solution doesn't work to me either.
The following suggested solution did not work for me either:
<meta content="width=device-width, height=device-height, initial-scale=1" name="viewport">

The issue compounds when using 'vw' or 'vh' to set the dynamic size of a font compared to its parent container.  If the parent div is always resizing on show/hide of the url bar on scroll, it makes the font its containing pop and resize regularly.

I really don't understand why the URL bar should have any effect on the size of the viewport.  It should be absolutely positioned over the content, and should not be present on page load.  It's an eyesore.  Perhaps someone can swipe down on page load to show the address bar, or have a tapping gesture to show it.  Maybe even a pull down tab.  Anything other than what it currently is.
Cc: bokan@chromium.org
This is, currently, the expected behaviour. When top controls are shown/hidden (for performance reasons the resize happens only once the user lifts their finger), the entire view that Blink is contained in is resized so changing the behaviour of just vh/vw would be inconsistent with the rest of the platform.

I'm investigating how to improve our overall behaviour here but it's not simple as there are many constraints. For example, the top controls must be present on page load and can't be programatically hidden for security reasons (prevent phishing attacks). I'd also like to move to a model where the top controls are overlaid directly on top of content, but that breaks the experience on sites with top position: fixed elements. Suggestions are appreciated but like I said, it's a complicated space so the ultimate solution isn't likely to be a silver bullet.
Please see comment #7 for my suggestions. I'd be happy to clarify anything, so please do ask if it isn't clear.
Comment 15 by b...@benknight.me, Mar 4 2015
This is still a frequent issue on many of my projects as a developer and I have no good fix for it so I just let Chrome Mobile users have a bad experience.  It not only affects viewport units, but it causes the a visual shift whenever a background image for the <body> is set to `background-size: cover`.

I understand the rationale for why this could be argued as expected behavior, but all of the developers who've chimed in here, including myself, still have a point.  It effectively breaks any styles that are coupled to the viewport.  Viewport size changes are expected when the window is resized or a device changes orientation, but not so with scrolling which is pretty much breaking the metaphor of dragging.  Scrolling on a mobile screen is conceptually similar to pushing a solid piece of paper across a surface.  That piece of paper wouldn't "grow" or "shrink" as you drag it.
Comment 16 by Deleted ...@, Mar 4 2015
I totally agree that this behaviour seems buggy and should be changed. Even worse is that the resizing is happening after the scroll stops. So the page jumps up and down whenever the user changes a scroll direction and all background-size:cover images in elements that are sized with viewport units (vh) will be rescaled.
Comment 17 by Deleted ...@, Mar 4 2015
PS.: iOS Safari handles this perfectly fine as the minimized browser bar is always used to calculate the viewport height.
Cc: -bokan@chromium.org
Labels: -Pri-2
Owner: bokan@chromium.org
Status: Assigned
Summary: Top Controls change layout viewport height (was: CSS viewport height changes on scroll making viewport units unusable)
Until this is fixed Developers have two options;

1. Let Chrome users have an obvious and undesirable judder as dimensions are recalculated
2. Don't use 'vh' as a unit of measurement.

Both are equally invalid because (1) UX is important and producing a jarring experience gives the impression the site is broken (rather than the browser, no matter how technically correct it is) and (2) 'vh' was created for expressly that purpose, to fill the height of the window.

As mentioned in #17, Mobile Safari handles this correctly even if we do have to compensate for it if there's content that gets hidden -- but that's par for the course.

Some proposed fixes off the top of my head that aren't thought through but might be the jumping point for a better solution;

1. Create a new addition to the (viewport?) META tag that makes Chrome set the vertical height as a constant (from the device height), rather than something that is recalculated when the menu/address bar is hidden.

2. Have it so anybody including height="device-height" in the META VIEWPORT property sets the height as a constant and not something that changes from the hiding or showing of the toolbar.

3. Just make "100vh" the device height. If there's 40-50px overhang (height of the menu) "outside" of the scrollable content then that's up to us, as Web Developers, to cater for -- we do this already with Safari Mobile.

The former seems overkill just for this issue, the second might have unforseen consequences in existing sites/apps, but the third would be preferable as we're already compensating for Safari Mobile so the same adjustment would kill two birds with one stone, so to speak.
Comment 20 by b...@benknight.me, Mar 17 2015
I found a workaround solution:

<style>
  html,
  body {
    height: 100%;
  }

  html {
    overflow: hidden;
  }

  body {
    overflow: scroll;
    -webkit-overflow-scrolling: touch;
  }
</style>

This causes the URL bar to never slide off the screen keeping the viewport at a fixed size.

Live example: http://democraticads.com
To #20 - Nice idea, but sadly that's not much of a workaround, as creates other problems as a result (bouncing position fixed els etc). 

To #13 - It seems that the concept for resizing here is being taken directly from desktop browsers, where the calculation of viewport units is clearly going to be directly tied to the size of the window itself. On devices, browser windows are not resizable (except through orientation change), so having the browser UI itself interfering with the dimensions / layout is quite frustrating, especially given the incredible utility of viewport units when making responsive layouts.  

Normalising the value of a viewport height unit to be without the browser interface (or its resting state) really would solve all these issues (as previous comments have said), and coincidentally make a number of quite beautiful design goals very achievable without gymnastics.

Would also probably have performance benefits as the browser would have to do less work. Current implementation is doing a lot of work which seems to bring no practical benefits. 
Comment 22 by bokan@chromium.org, Mar 31 2015
Labels: VirtualViewport-Improvements
Labels: Hotlist-Input-Dev
Comment 24 Deleted
Comment 25 by mit....@gmail.com, May 1 2015
#15 mentioned this, which I was about to open a new ticket for:

"It not only affects viewport units, but it causes the a visual shift whenever a background image for the <body> is set to `background-size: cover`."

I thought I made a good workaround for this, but was blocked by another issue. I set my body (for example) to have a height larger than the viewport, so that when you scrolled down, the background-image would not need to resize itself, and wouldn't produce a jarring image resize every time the address bar was hidden or shown. Unfortunately it turns out that the offscreen part of the background-image wasn't rendered at all. The space is there for the bottom of the image to show properly, but when you scroll up it is rendered as a solid color. Once you stop scrolling, the rest of background-image is shown. I have observed this behavior on iOS Safari as well.

Note that it still does not resize, as it didn't need to due to the body being made taller than the viewport. However the bottom offscreen chunk is shown as a solid block of color until you stop scrolling. There's more info on this on Stack Overflow:

http://stackoverflow.com/questions/23299960/prevent-fixed-position-background-image-cover-from-resizing-in-mobile-browsers/26226181#26226181
http://stackoverflow.com/questions/23776999/css-challange-background-image-with-100-height-white-space-when-scrolling-mo

If I should make a new issue I'd be glad to, but it seems similar in concept to this thread.
Comment 26 Deleted
My work around:

<style>
.hero {
  width: 100%;
  height: 100%;
  min-height: 100vh;
</style>

<script>
  $(document).ready(function() {
    var $hero = $('#hero');
    var h = window.innerHeight;
    $hero.css('min-height', h);
  });
</script>

<div id="hero" class="hero"><h1>Full Screen Background</h1></div>

Basically you're giving the div a static height, so the vh recalculation doesn't affect it.
Comment 28 by b...@benknight.me, May 12 2015
The bummer with that workaround is when changing device orientation the "hero" (in this case) won't adapt to the new viewport height.  The hero would either end up being too short or too tall when the orientation is changed.
Comment 29 by Deleted ...@, May 12 2015
Well, that was just a quick example. A more robust solution would recalc that height on the resize event.
Or even better, on the orientationchange event, since the address bar hiding triggers the resize event.
Comment 31 by b...@benknight.me, May 13 2015
Yeah this is absolutely possible so long as your use case for vh is setting an element to 100% of the viewport's height.  Shortly before filing this bug report I crafted this solution:
https://gist.github.com/benknight/0a13088c4f152639ed97

However the larger issue, as stated in the description, is that the computed value of 1vh still changes as the Top Controls (i.e. URL bar) slide out of view.  So anything that's based on the vh unit will suddenly change shift the layout.  For example: `font-size: 10vh` or `margin: 1vh`.  These are less common use cases but still unexpected behavior, undoubtedly.
Comment 32 by b...@benknight.me, May 20 2015
Here's another great example of this issue: https://learnsignal.com/
I'm not seeing this as an issue with Chrome 42.0.2311 anymore. Anybody else?
Comment 34 by b...@benknight.me, May 30 2015
I'm using Chrome 43.0.2357.78 and can confirm the issue as described is still present.  I tested https://learnsignal.com/.
Agreed. Same test on same version as #34. Still present.
I apologize. I seem to have mistakenly added a min-height which just happened to match exactly with the screen size height I was testing against. The issue is still present. 
Comment 37 by bokan@chromium.org, Jul 17 2015
Labels: M-46
Still present. Other browsers don't calculate 'vh' height with the URL bar. As far as I am aware, only Chrome does.

My site worked on iPhones, default browsers, but has this issue on Chrome.

WTB fix
Comment 39 by bokan@chromium.org, Jul 30 2015
Labels: Pri-1
Comment 40 by bokan@chromium.org, Aug 17 2015
Labels: -M-46 M-47
Labels: Hotlist-Polish
Comment 42 Deleted
Comment 43 by bokan@chromium.org, Sep 21 2015
Cc: jdduke@chromium.org aelias@chromium.org
Issue 510938 has been merged into this issue.
Comment 44 by b...@benknight.me, Sep 22 2015
I've seen a lot of activity on this bug recently.  Could someone on the Chromium team explain in plain English what status is here? Thanks :)
Comment 45 by bokan@chromium.org, Sep 22 2015
Labels: -Pri-1 -M-47 Pri-2
This is definitely a pain point for developers so it's something I'm looking to address. There are some significant consequences to changing how the top controls resize the page so a solution here will take some careful work and I've been busy with other issues at the moment so I haven't had a chance to prioritize this. That said, this is the top issue on my mind so when I get some time I'll take a look - I just can't make any promises on when that might be.
A new pain point with this behavior is responsive images that use vh/vmax/vmin; are their sources going to be chosen based on the initial or full screen height? Using `img {max-size: 90vh}` is also an emerging pattern for making sure the full image fits in the browser, which makes page jumps and reflow even worse.

WebKit's bug about their behavior for dealing with `vh` mentions using `position: fixed` as a workaround, as that specifically will scale with the viewport. (https://bugs.webkit.org/show_bug.cgi?id=141832) That might be an acceptable alternative for when this behavior is desired.
Comment 47 by bokan@chromium.org, Nov 24 2015
Status: Started
I wrote a temporary 'fix' in JavaScript for this, just make sure to call the function when the page loads.

function chromeViewportWorkAround() {
  var h = window.screen.height;
  if (navigator.userAgent.match(/Android/i) && navigator.userAgent.match(/Chrome/i)) {
    document.getElementById("drawer").style.height = h + "px";
  }
}

Replace the ID 'drawer' with the ID that should be 100vh.
Comment 49 by bokan@chromium.org, Nov 26 2015
Labels: M-49
Just to give a progress update, I'm intending to switch Chrome's behavior to be closer to Safari's. That is, for non-position: fixed elements, the initial containing block (the parent block for the root element) will not change size as the top controls hide/show. It will be sized to the viewport size when the top controls are shown. For position: fixed elements, the behavior will be unchanged: the ICB will resize as the top controls show/hide. This is how Safari (and Firefox, though it uses the viewport with top controls hidden for non-position fixed) behaves.

I hope to have this in for M49.
There seems to be a difference in how iOS Safari and Android Chrome work: in iOS the 100vh seems to always corresponds to the height of the window with the addressbar collapsed. If you pull up a 100vh/vw document in iOS Safari, it collapse the addressbar.

I want to achieve an app-like fixed header/collapsible sidebar layout without the jarring js-based positioning while scrolling, and without a position:fixed header blowing up on zoom. To do this, the nicest way seems to be a 100vh/vw body that uses flexbox and overflow:auto as appropriate.

However, this causes the addressbar in Android Chrome to always stay visible, and this is especially problematic in landscape.

it would be great if element scrolling or page interaction causes the addressbar to go away.

(to see a description of the fixed-position header blowup issue: http://dbushell.com/2013/09/10/css-fixed-positioning-and-mobile-zoom/)

Comment 51 by bokan@chromium.org, Dec 14 2015
Re #50: You're describing the problem that only scrolling in the <body> element affects top controls and other browser UI. I have a proposed solution to this @ https://github.com/bokand/NonDocumentRootScroller, would that address your issues?
That would be awesome!
NonDocumentRootScroller sounds like exactly the thing for this! +1000
Note that the https://github.com/bokand/NonDocumentRootScroller proposal would also fix the original issue: simply set the scroller to a non-scrolling element and the viewport size does not change.
Project Member Comment 55 by bugdroid1@chromium.org, Jan 20 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40

commit 7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40
Author: bokan <bokan@chromium.org>
Date: Wed Jan 20 17:56:40 2016

Don't change layout size due to top control show/hide.

This patch changes Chrome's top control (URL bar) behavior on Android
to match Safari's in how it affects layout size. To summarize, the
layout size or, equivalently, the initial containing block (ICB), is no
longer dynamically adjusted when the top controls are shown/hidden.
Instead the ICB is statically sized to be the size of the viewport when
top controls are showing. position: fixed elements are an exception,
they continue to work as they do today, resizing to mach the full
viewport size in response to top controls.

Additionally, vh units were changed in a similar way; they are now also
statically sized but to the size of the viewport with top controls
hidden.

See https://github.com/bokand/URLBarSizing for full details.

Intent to ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132

Review URL: https://codereview.chromium.org/1573283002

Cr-Commit-Position: refs/heads/master@{#370425}

[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/core/css/CSSToLengthConversionData.h
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/core/css/resolver/ViewportStyleResolver.cpp
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/core/frame/FrameView.h
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/core/frame/PageScaleConstraintsSet.cpp
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/core/frame/PageScaleConstraintsSet.h
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/core/layout/LayoutView.cpp
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/core/layout/LayoutView.h
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/web/WebViewImpl.cpp
[modify] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/web/tests/TopControlsTest.cpp
[add] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/web/tests/data/percent-height.html
[add] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/web/tests/data/vh-height-width-800-extra-wide.html
[add] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/web/tests/data/vh-height-width-800.html
[add] http://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40/third_party/WebKit/Source/web/tests/data/vh-height.html

Project Member Comment 56 by bugdroid1@chromium.org, Jan 20 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4

commit f656eeb17cf8de94f6c6fc10671f9a06b6c98de4
Author: sgurun <sgurun@chromium.org>
Date: Wed Jan 20 21:01:39 2016

Revert of Don't change layout size due to top control show/hide (patchset #13 id:240001 of https://codereview.chromium.org/1573283002/ )

Reason for revert:
speculative reverts for https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29%281%29/builds/51570

see crbug/579666

Original issue's description:
> Don't change layout size due to top control show/hide.
>
> This patch changes Chrome's top control (URL bar) behavior on Android
> to match Safari's in how it affects layout size. To summarize, the
> layout size or, equivalently, the initial containing block (ICB), is no
> longer dynamically adjusted when the top controls are shown/hidden.
> Instead the ICB is statically sized to be the size of the viewport when
> top controls are showing. position: fixed elements are an exception,
> they continue to work as they do today, resizing to mach the full
> viewport size in response to top controls.
>
> Additionally, vh units were changed in a similar way; they are now also
> statically sized but to the size of the viewport with top controls
> hidden.
>
> See https://github.com/bokand/URLBarSizing for full details.
>
> Intent to ship:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4
>
> BUG=428132
>
> Committed: https://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40
> Cr-Commit-Position: refs/heads/master@{#370425}

TBR=jbroman@chromium.org,aelias@chromium.org,bokan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=428132

Review URL: https://codereview.chromium.org/1611693002

Cr-Commit-Position: refs/heads/master@{#370486}

[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/core/css/CSSToLengthConversionData.h
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/core/css/resolver/ViewportStyleResolver.cpp
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/core/frame/FrameView.h
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/core/frame/PageScaleConstraintsSet.cpp
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/core/frame/PageScaleConstraintsSet.h
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/core/layout/LayoutView.cpp
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/core/layout/LayoutView.h
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/web/WebViewImpl.cpp
[modify] http://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4/third_party/WebKit/Source/web/tests/TopControlsTest.cpp
[delete] http://crrev.com/7266ef121b89d557475187e08e226997fceef9c0/third_party/WebKit/Source/web/tests/data/percent-height.html
[delete] http://crrev.com/7266ef121b89d557475187e08e226997fceef9c0/third_party/WebKit/Source/web/tests/data/vh-height-width-800-extra-wide.html
[delete] http://crrev.com/7266ef121b89d557475187e08e226997fceef9c0/third_party/WebKit/Source/web/tests/data/vh-height-width-800.html
[delete] http://crrev.com/7266ef121b89d557475187e08e226997fceef9c0/third_party/WebKit/Source/web/tests/data/vh-height.html

Project Member Comment 57 by bugdroid1@chromium.org, Jan 20 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bad329b1d221172a0da9a2b09f5decbe86a6cd43

commit bad329b1d221172a0da9a2b09f5decbe86a6cd43
Author: sgurun <sgurun@chromium.org>
Date: Wed Jan 20 22:55:12 2016

Reland of Don't change layout size due to top control show/hide (patchset #1 id:1 of https://codereview.chromium.org/1611693002/ )

Reason for revert:
does not look like related to crbug/57966, probably the test is flaky

relanding

Original issue's description:
> Revert of Don't change layout size due to top control show/hide (patchset #13 id:240001 of https://codereview.chromium.org/1573283002/ )
>
> Reason for revert:
> speculative reverts for https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29%281%29/builds/51570
>
> see crbug/579666
>
> Original issue's description:
> > Don't change layout size due to top control show/hide.
> >
> > This patch changes Chrome's top control (URL bar) behavior on Android
> > to match Safari's in how it affects layout size. To summarize, the
> > layout size or, equivalently, the initial containing block (ICB), is no
> > longer dynamically adjusted when the top controls are shown/hidden.
> > Instead the ICB is statically sized to be the size of the viewport when
> > top controls are showing. position: fixed elements are an exception,
> > they continue to work as they do today, resizing to mach the full
> > viewport size in response to top controls.
> >
> > Additionally, vh units were changed in a similar way; they are now also
> > statically sized but to the size of the viewport with top controls
> > hidden.
> >
> > See https://github.com/bokand/URLBarSizing for full details.
> >
> > Intent to ship:
> > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4
> >
> > BUG=428132
> >
> > Committed: https://crrev.com/7ea490e3e6a79cc1e7fd4d952bcc36b2ad38cf40
> > Cr-Commit-Position: refs/heads/master@{#370425}
>
> TBR=jbroman@chromium.org,aelias@chromium.org,bokan@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=428132
>
> Committed: https://crrev.com/f656eeb17cf8de94f6c6fc10671f9a06b6c98de4
> Cr-Commit-Position: refs/heads/master@{#370486}

TBR=jbroman@chromium.org,aelias@chromium.org,bokan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=428132

Review URL: https://codereview.chromium.org/1612683002

Cr-Commit-Position: refs/heads/master@{#370519}

[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/core/css/CSSToLengthConversionData.cpp
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/core/css/CSSToLengthConversionData.h
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/core/css/resolver/ViewportStyleResolver.cpp
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/core/frame/FrameView.h
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/core/frame/PageScaleConstraintsSet.cpp
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/core/frame/PageScaleConstraintsSet.h
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/core/layout/LayoutView.cpp
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/core/layout/LayoutView.h
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/web/WebViewImpl.cpp
[modify] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/web/tests/TopControlsTest.cpp
[add] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/web/tests/data/percent-height.html
[add] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/web/tests/data/vh-height-width-800-extra-wide.html
[add] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/web/tests/data/vh-height-width-800.html
[add] http://crrev.com/bad329b1d221172a0da9a2b09f5decbe86a6cd43/third_party/WebKit/Source/web/tests/data/vh-height.html

Comment 58 by bokan@chromium.org, Jan 21 2016
Labels: -M-49 M-50
Status: Fixed
This is now landed (changes described in https://github.com/bokand/URLBarSizing) and, barring any compat issues in Beta, should ship with Chrome M50. You'll be able to see the changes in Chrome Dev Channel on Android in a week or two - I'll update this bug when that's available to try.

I've noticed lots of possibly related, possibly separate discussion above. If you still see related bugs or these changes don't address them, please file new bugs.
Thank you! Your dev efforts are very much appreciated.
Comment 60 by b...@benknight.me, Jan 21 2016
It's been great to follow the progress made here from the day I reported the issue to having a fix in production! It's interesting how even a small feature like this can create an interoperability mess among clients.  Based on your Github explainer page I'm not sure it's the last time developers will have frustrations related to this not working the same among browsers.  I think the general concept of having a static ICB that doesn't change until the user specifically performs some action that would cause an expected layout recalc would be a good standard for browsers to implement.  In other words, the ICB only changes when the user resizes the client either by resizing the window or changing orientation.
Wow, what perfect timing. Thanks everyone!
One creative solution can be adding to your div with 100vh, the css rule transition: height 999999s. It solved my problem!
That's really creative, but not exactly optimal. Thanks!
Another solution:

	function greedyJumbotron() {
	    var HEIGHT_CHANGE_TOLERANCE = 100; // Approximately URL bar height in Chrome on tablet

	    var jumbotron = $(this);
	    var viewportHeight = $(window).height();

	    $(window).resize(function () {
	        if (Math.abs(viewportHeight - $(window).height()) > HEIGHT_CHANGE_TOLERANCE) {
	            viewportHeight = $(window).height();
	            update();
	        }
	    });

	    function update() {
	        jumbotron.css('height', viewportHeight + 'px');
	    }

	    update();
	}

	$('#jumbotron').each(greedyJumbotron);
Comment 65 by b...@benknight.me, Jan 30 2016
That's actually probably the best (i.e. simplest) hack solution I've seen for this.  Well done.
#62 Unfortunately it doesn't really 'solve' the problem. When the user change the device orientation it creates another problem.

I found another solution in the same thread and it's fully working for me.
http://stackoverflow.com/a/28532659/4953313

function greedyJumbotron() {
    var HEIGHT_CHANGE_TOLERANCE = 100; // Approximately URL bar height in Chrome on tablet

    var jumbotron = $(this);
    var viewportHeight = $(window).height();

    $(window).resize(function () {
        if (Math.abs(viewportHeight - $(window).height()) > HEIGHT_CHANGE_TOLERANCE) {
            viewportHeight = $(window).height();
            update();
        }
    });

    function update() {
        jumbotron.css('height', viewportHeight + 'px');
    }

    update();
}

$('.greedy-jumbotron').each(greedyJumbotron)
Comment 67 by bokan@chromium.org, Feb 23 2016
Blockedon: 586872
Project Member Comment 68 by bugdroid1@chromium.org, Feb 24 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cc87033da754d1ec0a34e0dd39798f67fc132085

commit cc87033da754d1ec0a34e0dd39798f67fc132085
Author: bokan <bokan@chromium.org>
Date: Wed Feb 24 16:53:36 2016

Put Top Control resizing change behind a flag.

The change to how top controls affect VH units and the initial containing
block was made in r370425. We've decided to hold off on shipping that change
for now so I've placed this change behind a flag. Unless the inert-top-controls
experiment is enabled, the behavior is unchanged from M49.

BUG=428132

Review URL: https://codereview.chromium.org/1721883003

Cr-Commit-Position: refs/heads/master@{#377309}

[modify] https://crrev.com/cc87033da754d1ec0a34e0dd39798f67fc132085/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/cc87033da754d1ec0a34e0dd39798f67fc132085/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in
[modify] https://crrev.com/cc87033da754d1ec0a34e0dd39798f67fc132085/third_party/WebKit/Source/web/WebViewImpl.cpp
[modify] https://crrev.com/cc87033da754d1ec0a34e0dd39798f67fc132085/third_party/WebKit/Source/web/tests/TopControlsTest.cpp

Comment 69 by bokan@chromium.org, Feb 24 2016
Status: Started
Update: I've actually put this behind a flag for M-50 as there's still some kinks to work out and also we're hopeful we can get Safari on the same page and make % match vh units so I'd rather hold off for a milestone or two rather than churning behavior in stable.

Interested authors can try out the new behavior by going to chrome://flags and turning on the 'experimental-web-platform-features' flag in M50. I'm hopeful that we can ship this around M51 or M52.
Cheers, thanks for your hard work.
On Feb 24, 2016 11:58 AM, "bokan@chromium.org via Monorail" <
monorail@chromium.org> wrote:
Comment 71 by pdr@chromium.org, Mar 4 2016
Cc: dominicc@chromium.org yus...@chromium.org dominickn@chromium.org dfalcant...@chromium.org
Issue 586872 has been merged into this issue.
Cc: mlamouri@chromium.org
Issue 598628 has been merged into this issue.
Here's a version of the solution in #66 that doesn't require jQuery, and also takes into account height values other than 100vh.

function stabilizeVH(element) {
    var HEIGHT_CHANGE_TOLERANCE = 100; // Approximate height of URL bar in Chrome on tablet
    var viewportHeight = window.innerHeight;
    var elementHeight = element.offsetHeight;
    var originalElementPercent = element.offsetHeight / viewportHeight;

    window.addEventListener('resize', function() {
        if (Math.abs(viewportHeight - window.innerHeight) > HEIGHT_CHANGE_TOLERANCE) {
            viewportHeight = window.innerHeight;
            elementHeight = window.innerHeight * originalElementPercent;
            update();
        }
    });

    function update() {
        element.style.height = elementHeight + "px";
    }

    update()
}

var elements = document.querySelectorAll(".stabilizeVH");
for (var i = 0; i < elements.length; i++) {
    stabilizeVH(elements[i]);
}
Comment 74 by mar...@duotones.ch, Apr 15 2016
Having the same issue here, but not only for vh but also for elements that have a percentage height. Just yesterday I've rebuild a complex full-height page with percentage instead of vh to address this issue, however the problem remained, so I went back for vh and set every vh with javascript, if it's a mobile device (Is there any way to check if it's chrome, but only mobile, regardless if android or iOS?).
Cc: komoroske@chromium.org slightlyoff@chromium.org
Labels: -Pri-2 Pri-1
This regression has since landed in stable, making most of our PWAs look visually broken.

This is definitely P1, might even be P0 due to PWAs being a huge part of our I/O story, and anyone who tries them out today is going to get a broken experience.
By bad, this bug only exists in stable with experimental-web-platform-features on, but this bug must not land in flagless stable.

Screenshot attached showing the gap at the bottom of the UI.
nexus5.png
153 KB View Download
There's no regression here, this is suggested changed functionality that's currently behind the --enable-experimental-web-platform-features flag. What exactly is the issue you're seeing?
As of now, there's no plan to turn this on stable yet but it's something that's on my list to do in the coming quarter or two.

Jake, we're looking to match Apples's behavior here, how does this example look on iOS safari? Could you send me a repro?
Cc: rbyers@chromium.org owe...@chromium.org
With --enable-experimental-web-platform-features almost all PWAs have a gap at the bottom of the page.

This includes, but probably isn't limited to:

https://jakearchibald.github.io/svgomg/
https://jakearchibald-gcm.appspot.com/
https://voice-memos.appspot.com/
https://guitar-tuner.appspot.com/

To reproduce, launch one of the above PWAs from the homescreen. You'll see a gap at the bottom of the screen.

iOS doesn't appear to have this issue. Screenshots attached.
no-flag.png
68.8 KB View Download
with-flag.png
69.6 KB View Download
ios.png
58.3 KB View Download
Looks like the layout for:

html,body { height: 100%; }

…isn't quite 100%.
Right, on Safari and Chrome w/flag, height: 100% means full height *with top controls down*, but hiding top controls doesn't update the height. The gap seems to be smaller than top controls (interestingly, looks awfully close to the size of the notification bar) so it seems like perhaps something else is going on. The fact that it's working on Safari also indicates a difference or a bug.

Thanks for the heads up, I'll look more closely into this shortly.
Labels: -Pri-1 Pri-2
Downgrading this to P2. This is important, but I don't think it's a P1.
Is there any ETA on when this bug will be fixed and release to stable?
Comment 85 by bokan@chromium.org, Jul 18 2016
Unfortunately, nothing concrete. It's still on my todo-list but I've had to prioritize other work. I'm currently aiming for M55 but that's a rough estimate at best.
With regards to the addition of a 'scroll anchoring' flags option - did that have anything to do with this..? It's possibly related as the recalculation of what 1vh means in terms of element size also seems to cause the reflow of offscreen content. 

I'd hope that the fixes discussed above are still going to land, even with the addition of this option. Thanks for attention and appreciate complexity involved.
Cc: skobes@chromium.org
+skobes@ for scroll anchoring thoughts.

Scroll anchoring isn't on by default yet, but top controls causing relayouts could activate the anchor. I think that's generally what you'd want, if a vh sized image above the viewport causes the content to shift because of top controls hiding/showing, you'd want to anchor to the location you were viewing before hiding/showing the controls.
Scroll anchoring doesn't directly affect the treatment of vh units, but it can (partially) mitigate content shifts caused by the resizing of elements measured in vh units (see issue 626258).

I think the work described in https://github.com/bokand/URLBarSizing is still worth pursuing.
Cc: -dfalcant...@chromium.org
I just happened to realise, the resizing is also happening when focusing on an input and the keyboard appears.
I think the keyboard should be a fixed positiinned element that just appears on top of the site/app.
We're considering making that change already, see issue 404315. You can try it out with chrome://flags/#enable-osk-overscroll.
Hey guys, any updates on this? I am blown away that this has been an issue for two years. If it's not going to be released anytime soon, does anyone have a current, up to date workaround?
I am using this workaround:
Use height 100% instead of 100vh.

set body height to 100% in CSS, and insert a DIV with height 100% which will contain whole page (You can put elements with 100% height instead of 100vh inside this DIV to make them cover complete height)! then on page load set this DIV's height using - 
DIV.style.height = document.body.clientHeight;
Then attach a resize event listener to Window which does this: 
if difference in height is less than 60px (anything more than url bar height) then do nothing and if it is greater than 60px then set DIV's height again to body height!

Do tell if anybody has a better solution than this! This bug is so irritating!
Comment 94 Deleted
Comment 95 by drax...@gmail.com, Sep 15 2016
This is still a bug, but here is a working solution:

body::after {
    content: '';
    position: fixed;
    top: -100px;
    bottom: -100px;
    left: 0;
    right: 0;
    background-color: rgba(0,0,0, .5);
    z-index: 1;
}

This doesn't create any overflow bugs. Tested in Android and IOS Chrome (latest version)

Please say if this doesn't work for some mobile browser/version
Comment 96 by gang...@gmail.com, Sep 29 2016
Dear Chromium community,

This issue will celebrate it's 2nd birthday soon.
Can one of you tell me please what is the plan for fixing it?
There was a promise to ship a fix in the 50th release. Now Chrome is in the 53rd stable release and still no sign of any fix.
If the behavior is expected as it is, then please describe a workaround how a div could be always fill the whole height of the viewport without the resizing effect when the address bar moves away.

Thank you.
Cc: sshruthi@chromium.org
+sshruthi@

This is one of the most-starred open issues in the Blink component; would making this a release blocker for an upcoming milestone be appropriate to make sure we get some traction here?  Is Pri-2 really still appropriate?
Comment 98 by bokan@chromium.org, Sep 29 2016
Labels: -Pri-2 Pri-1
I'm planning on focusing on this in the coming quarter but this isn't a bug per-se so I'm not sure making it a release blocker is appropriate, there's web compat issues to consider so it's not clear how easy that'll be to change. I'll bump the priority to indicate increased urgency here.

Re comment #96: Sadly, I don't think there's a satisfactory workaround short of hardcoding values for the size of the URL bar which feels like a bad idea. The easier thing to do would be to size the DIV to the size of the viewport while top controls are shown so they don't change size on scroll but it'd be smaller than the viewport when the top controls hide.
Comment 99 by bokan@chromium.org, Sep 29 2016
Labels: -M-50 M-56
Comment 100 by gang...@gmail.com, Sep 30 2016
Dear Chromium community,

I've invested time into this issue and have read lot of things.
Summarizing:
1. Having the same issue with the same behavior on all/most of the browsers is a good thing since then the workaround fix could be the same for all the platforms.
2. If the workaround is such a pain in the ass(sorry for the strong expression) then the 1st point is violated.
3. Apple did not come up with any suggestion however they did have 2 years for doing so. They are also ignoring your pings AFAIK.
4. Market shares for mobile platforms based on the available public data from IDC:
http://www.idc.com/prodserv/smartphone-os-market-share.jsp
Android: between 80-90%
iOS: between 10-20%
others: no comment

Which means most of the users on the mobile platforms are using Chrome or Firefox or the built-in browser or any other 3rd party that is available on the google Play Store. But definitely not Safari is the market leader in the mobile area as it does not have an Android port AFAIK.

Browser statistic:
http://gs.statcounter.com/
Chrome is a leader here.

So based on this I think we can say you guys are the market leader. As the market leader you have the most ability to drive the change and move things forward.

The next question is how painful way you choose to doing it for web developers, browser vendors, and end-users.

The most overbearing solution if you just change how chrome is handling 100vh value. In this case everyone needs to adapt their part.

Describing 3 possible behavior:
1. Keep the current behavior because it does not affects contents that are not using vh values. Valid use-case for them at the moment, not valid for the future and the peoples those who wants to use vh values now.
2. 100vh=maximal viewport size = when the addressbar is not shown
3. 100vh=minimal viewport size = when the addressbar is shown

The connection between them can be AND or OR based on your overbearing preference.

If you want to choose to just handle the 100vh in a standardized way inside chrome without any outside control then web developers are not going to be very happy as well I think.

So my suggestion is(if it's feasible):
Using the viewport meta tag give the ability for the developers to be able to choose from the above 3 behavior which he/she wants to use. This meta tag is not standardized by W3C I know but still everyone is familiar with it who wants to develop responsive website.
With this solution there is also a high chance that none of the existing browser behavior would be broken until they are handling the unknown meta data as ignored or implements the same way.

Thank you for reading and your hard and excellent work!
Comment #100: I think we could have a 4th solution which could be quite easy to implement and would make everything a lot easier. The browser could add like a margin at the top of the website, if the height of the address bar, the address Barr being in a position "fixed" when scrolling up, this margin would always be covered and the size of the viewport would never change, just like you would handle a fixed Mac bar on a website.
Comment #100: Sadly, I don't think it's as simple as any of these solutions. For example, if you look at our Minute content type: https://www.theguardian.com/us-news/live/2016/sep/29/trump-cuba-embargo-allegations  

- When you first load the page, it is important that the text along the bottom is not cut off, as well as the logos on the top be visible. In that case, 100vh *must* be equal to the window minus the visible url bar. 
- When you scroll and the url bar disappears, each 'block' should be the height of the entire viewport. In that case, 100vh *should* be equal to the window - if it isn't the UX of the page is poor as you end up with some of the next block appearing instead of the 'full page' effect we're going for.

In that case, how do you handle that difference? Hide the url bar on load (whole host of other UX issues)? Leave current behaviour but throttle the resize of 100vh until scroll completes? 

This isn't simple and thanks to +bokan@ for picking it up - if I can help test this in any way, please let us know.
Comment 103 by gang...@gmail.com, Sep 30 2016
I see your point.
You have contents on the page. Every content should fill the entire viewport regardless the status of the address bar.But I have a bad news.
The address bar can popup everywhere on the page regardless how far are you from the top. For this you need the 1st setting and to be honest I don't know how to omit in this case at all the jumping effect. :(
> The address bar can popup everywhere on the page regardless how far are you from the top.

Indeed. That's less of an issue though - on load, I want to fill the (window - url bar) with my first block. But if a user scrolls up half way though an article, it doesn't matter if the url bar slides in and covers content, as long as when they scroll down and it disappears, the blocks still fill the window.

Maybe our specific usecase here is - 

.block { height: 100vh } // Fix me here, don't change on scroll
.block:first-of-type { height: calc(100vh - heightOfUrlBar)} // Fix at shorter height, and deal with slight annoyance when user scrolls


There's another solution to consider, which seems pretty neat regarding the ever growing size of smartphone displays. Make vh the full-screen size always, and put the addressbar at the bottom, it would be much easier to reach and for the "the guardian behaviour" you could just simply place elements "bottom: x+"address bar height" in chrome mobile. I know this would affect the browser itself and its UX, but in my opinion towards a better UX. The addressbar at the bottom was possibly the only one thing that was an advantage of mobile IE against other browsers.

Another solution to consider might also be to consider vh as the full-height without addressbar and to have an additional min-vh attribute that would, if given, overwrite the vh in case of mobile chrome. Something like this:

.full-height {
  height: 100vh;
  height: 100min-vh;
}

But yeah that's not a W3C compatible way. Just some food for thought.
I may be in the minority, but all I really care about is that -either- option (100vh = with big address bar, or 100vh = with small/no address bar) is implemented.

With how it is right now, I can't even use VH units because of the poor experience that it provides to a very large portion of my visitors - due to the fact that content jumps when around as you scroll. (Also, the fact that Chrome, and not IE9 - which I currently have to support - is preventing me from using a CSS feature is really weird :P ) 

Having one of them implemented means that I can at least start using VH units and make adjustments as necessary to get the desired layout.

Thanks everyone for the continued discussion on workarounds and implementation details. Hopefully this can get resolved soon.
Gareth, what would actually be the problems on hiding the Url bar on load? I think it could be a pretty sweet solution..
Hiding the URL bar on load is a security concern since it allows a page to emulate the URL bar and do all sorts of malicious things. 
Do you actually think so? I believe people are not so fool. And if someone gets into this, a simple scroll, even made by mistake, would automatically alert the user.
The idea of hiding the url bar make sense to me as when I go on a website, I wanna see the website's content, not the url bar or any menu kinda thing. And if so, it would be very easily accessible if when something get's loaded I see the bar slidding in the top.
Moreover, it would definitely go in Google Chrome's direction in hiding the top controls as much as possible to give the user the most "full page" experience possible.
This was mentioned a long time ago but I think is worth mentioning again. What about making the address bar float over content? Make 100vh the full height of the browser window. On page load, the address bar is floating over content and upon scroll or a couple seconds (whichever is earlier) the bar floats away. IT can still comes back when someone pulls down but would re-appear over the content, not shifting the content and changing its height.
I would add another notice.
When the keyboard fires up on such a page then it's also changing the vh values same as the address bar.
Blockedon: 565930
What is current accepted workaround that works ? I git a jerky scroll motion since most of my divs are viewport sized. 
Project Member Comment 114 by bugdroid1@chromium.org, Nov 4 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7f8de7508a3e8098ed174c59daa5b068808382f8

commit 7f8de7508a3e8098ed174c59daa5b068808382f8
Author: bokan <bokan@chromium.org>
Date: Fri Nov 04 01:42:16 2016

Enable inert top controls (URL bar) in stable.

Approval to ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4

BUG=428132

Review-Url: https://codereview.chromium.org/2480523002
Cr-Commit-Position: refs/heads/master@{#429759}

[modify] https://crrev.com/7f8de7508a3e8098ed174c59daa5b068808382f8/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in

Woo-hoo! Thanks to everyone involved
Status: Fixed
If all goes well, this will ship in M56 and should start showing up in Canary in the next day or two. See https://github.com/bokand/URLBarSizing for details and demo and please file bugs if you see them! Thanks.
Also chromestatus entry is: https://www.chromestatus.com/features/6241601772847104

Comment 118 by gang...@gmail.com, Nov 18 2016
Hi all,

First of all thank you for everyone who has been involved to fix this issue.
Bokan I would like to check your fix however I have 2 issues.
Once I install the provided APK (ChromePublic.apk under: https://github.com/bokand/URLBarSizing)
and start the app it crashes.
Does it needs Play services or anything else to be installed?

The 2nd thing that I did notice that the APK is almost 1year old.

So is this the right APK to be able to try?

Thank you.
This is now on by default in Chrome 56 (currently Dev channel), so there's no need to use the APK at all.  Please try Chrome Dev and let us know how it works for you.  We'll fix the text in the repo, thanks!
Just tried it, works awesome!!!
Thanks to everyone involved!
Comment 121 by gang...@gmail.com, Nov 19 2016
Hi,

I just made a test over my page.
I would expect that the Stable Chrome and the Chrome_Dev are showing the same view when the address bar is shown.(Am I wrong?)
That's actually not the case.
See the attached screenshot.
You can see the Tablet is hidden by the red part on Chrome_Dev.
I'm using vh units for setting the hight for both images.
Chrome_Dev.png
535 KB View Download
Chrome_stable.png
552 KB View Download
Hi, I do not see the difference in the screenshots you provided.
And when the address bar shown, both view cannot be the same and that was the problem. The chrome dev already calculates a 100vh as if the address bar was a part of the height, which makes sense as it disappears afterwards. And if I'm not mistaking, Safari on Iphones work the same way.
Comment 123 by gang...@gmail.com, Nov 19 2016
"You can see the Tablet is hidden by the red part on Chrome_Dev."

Or just open the attachment in two browser tabs next to each other and you will see the difference.

The viwportsize are the same at least when visiting the http://viewportsizes.com/mine/ with Chrome stable and Chrome_Dev
And thats makes me confused.
If I have the exactly same viewport size for both the 2 browser how could be the  view different then?
Comment 124 by gang...@gmail.com, Nov 19 2016
Another problem is that on a desktop machine which is used for development I can not reproduce the same view when setting the viewport size to the exactly same as on the mobile.
So there is also an inconsistency now between the desktop and mobile browser.
Re#121: If you're using vh units then there will be a difference. In Dev, 100vh will fill the entire viewport as if the URL bar was hidden (even if its not). On stable, 100vh will resize as the URL bar is hidden and shown. This means 100vh with URL bar showing is smaller in stable than it is in dev.

Re#124: Unfortunately, we do miss some of the quirks of mobile browsers in DevTools and I agree it would be helpful to more faithfully emulate this. However, that's true today as well since you can't show the URL bar AFAIK. I've filed issue 667278, feel free to star that if its something you'd find useful.
Comment 126 by gang...@gmail.com, Nov 22 2016
Hi,

Okay now I understand it. Thank you for the clarification. Also was able to fix my issue.
Comment 127 by gang...@gmail.com, Nov 29 2016
Hi,

Now I have an issue with the media queries.
Let's use the Samsung Galaxy S2 as the reference device in portrait:
Device width: 480px
Device height: 800px
CSS width: 320px
CSS height: 533px
Pixal ratio: 1.5

It means for me that in Chrome stable the viewport size is(in CSS pixel) with showing address bar in portrait orientation:
320 x 452

And when the address bar is hidden:
320 x 508
----------------------------------------------
The same scenario with the Chrome_Dev should be in both cases:
320 x 508 Because AFAIK the viewport size stays at the maximum value regardless the status of the address bar.

Is my assumption OK or do I still miss something?

"This means 100vh with URL bar showing is smaller in stable than it is in dev."
Actually this is not the case when visiting the page with Chrome Stable and Chrome Dev:
http://viewportsizes.com/mine/
Viewport is a very ambiguous term these days so you need to specify exactly what you're referring to.

> The same scenario with the Chrome_Dev should be in both cases:
> 320 x 508 Because AFAIK the viewport size stays at the maximum
> value regardless the status of the address bar.

-An element with `height: 100vh` will be 508 pixels in height.
-An element with `position: absolute; height: 100%` will be 452 pixels in height.
-An element with `position: fixed; height: 100%` will be 452 pixels in height when top controls are shown, 508 pixels in height when top controls are hidden.
-window.innerHeight will be 452 when the URL bar is showing, 508 when hidden.

The "viewport" used for vh units (lets call it the "vh viewport") is what you're referring to here, it stays at the maximum size.
The "viepwort" used to size other elements, also known as the "initial containing block", stays at the minimum size.
The "viewport" as seen by the user (the "visual viewport"), returned by window.innerHeight, is dynamic and changes as top controls show and hide.

The ICB is used as the root element for layout.
The vh viewport is used only for vh units.
The visual viewport is used for position: fixed elements.

> > "This means 100vh with URL bar showing is smaller in stable than it is in dev."
> Actually this is not the case when visiting the page with Chrome
> Stable and Chrome Dev: http://viewportsizes.com/mine/

This page doesn't measure the "vh viewport". It measures document.documentElement.clientHeight which is derived from the initial containing block. Chrome stable changes the size of the ICB when you show/hide the top controls so you'll see the displayed viewport height change. Chrome dev keeps the ICB at the minimum height so you'll see the smaller of the heights and it won't change.

Hope that clears things up. Happy to answer more questions if you've got em.
Comment 129 by gang...@gmail.com, Nov 30 2016
Hi,

Thank you for your detailed answer. It clears things.
My last question would be what about height based media query's.
For example I have 2 rules:

@media (orientation: landscape) {
::id > div { 
top: 65px; 
left: 10vw; 
min-width: 120px; 
} 
}

@media (orientation: landscape) and (min-height: 241px) {
::id > div { 
top: 27vh; 
} 
}

The case is that on Samsung Galaxy S2 with Chrome_DEV and in Chrome Stable the first query will be applied WHEN the address bar is shown.
When the address bar is hidden then on Chrome_DEV still the first query will applied but on the Chrome_Stable it's now the 2nd.

How can this issue be solved?

Thank you.
Media queries on height refer to the initial containing block size so that no longer changes.  I've confirmed this matches Safari's behavior.

There is no full-proof and interoperable way to tell when the URL bar is showing on the web. You can use some heuristics which might get most of the way but they'll have edge cases and could break with browser updates.

That said, if you still want to do something in response to the "visual viewport" changing height, you can still do so with some JS. We fire a resize event and you can read out window.innerHeight and use that.
Hi,

okay, thank you for your help!
Do you have any estimation how much would it take to arrive this change into the Chrome Stable for android?
You're welcome. As long as the change sticks (there's still a chance we'll find bugs or unexpected compat impact and have to delay) in M56 it should be in stable early February.
http://bokand.github.io/demo/urlbarsize.html - when open Chrome DEV Tools in same window right-side, it shows the same window.innerHeight and documentElement.clientHeight then without DEV Tools, it perhaps might be considered as a bug.
I'm not sure I understand, if the Dev tools window is on the right side, it's taking horizontal space away, innerHeight/clientHeight shouldn't change. In any case, that's on desktop which isn't affected by this bug. Feel free to file a new bug and we can follow up there.
I just discovered this discussion, and since I'm currently writing an article about exactly this problem I'd like to be sure of what is being changed.

In the future, 100vh will use the visual viewport height *without* the browser toolbar and the keyboard as its reference, correct? So an element with height: 100vh will take up the height it needs in the absence of all toolbars and keyboards, correct?

I would support that change; it makes excellent sense.

One question, though: what value will window.innerHeight expose? The maximum visual viewport height that's also going to be used for 100vh, or the actual current visual viewport height (i.e. its value changes as toolbars and keyboards pop open or close)?

Thanks,
Hey ppk, this just shipped to stable in M56 so the current behavior is:

100vh is sized to be the "maximum possible viewport height". So that if the URL bar is shown, 100vh will be larger than the visual viewport. If the URL bar is hidden, it is exactly the visual viewport height. Your interpretation is correct, except for the keyboard still causes us to reflow the page - I have plans to change that this quarter in issue 404315.

window.innerHeight remains unchanged. It'll still expose the actually current visual viewport height.

Note, there's a difference between setting `height: 100%` on <html> and `height: 100vh`. The former will use the "smallest possible viewport" - so if the URL bar is hidden, it'll be smaller than the visual viewport. If it's shown, it'll be exactly the visual viewport height. This is an unfortunate inconsistency but was done to match the behavior of Safari. I'd like to either make % and vh consistent or add a CSS style to let you choose which you'd prefer (a la box-sizing). In any case, interop with Safari is most important here.

More details are here:

https://developers.google.com/web/updates/2016/12/url-bar-resizing
https://github.com/bokand/URLBarSizing
With Chrome for Android 56 I experience 100vh to be off by 22px (height of the status bar) when starting an app full-screen from the home screen. The problem does not appear when opening it in Chrome browser.

Not sure if this is strictly related.
Yeah, that's related and a bug. See issue 688738. 
Thanks! Sorry, I didn't find it before commenting.
Comment 140 Deleted
Hello,

I am still having this bug on iOS Chrome (document.documentElement.clientHeight changes with status bar resize, 100vh is not a constant height), and I was wondering if there is any plan to fix it, or if there is a solution of which I'm unaware?

Thank you!
Chrome on iOS is separate from Chrome on Android in many ways but I agree it would be helpful for interop to fix this. I've filed issue 720048 to track that, feel free to star that bug to follow any progress.
Project Member Comment 143 by bugdroid1@chromium.org, Jun 9
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f628aefdd7302fc33611b9fedc129a4e1fb19b1d

commit f628aefdd7302fc33611b9fedc129a4e1fb19b1d
Author: David Bokan <bokan@chromium.org>
Date: Fri Jun 09 17:48:32 2017

Remove InertTopControls RuntimeEnabledFeature

This feature has been in stable since M56 so it's safe to remove the
flag now.

Bug: 428132
Change-Id: I11341acde13034262899e072941b59667847c70d
Reviewed-on: https://chromium-review.googlesource.com/528225
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#478325}
[modify] https://crrev.com/f628aefdd7302fc33611b9fedc129a4e1fb19b1d/third_party/WebKit/Source/core/frame/LocalFrameView.cpp
[modify] https://crrev.com/f628aefdd7302fc33611b9fedc129a4e1fb19b1d/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5
[modify] https://crrev.com/f628aefdd7302fc33611b9fedc129a4e1fb19b1d/third_party/WebKit/Source/web/WebViewImpl.cpp
[modify] https://crrev.com/f628aefdd7302fc33611b9fedc129a4e1fb19b1d/third_party/WebKit/Source/web/tests/BrowserControlsTest.cpp
[modify] https://crrev.com/f628aefdd7302fc33611b9fedc129a4e1fb19b1d/third_party/WebKit/Source/web/tests/VisualViewportTest.cpp

Sign in to add a comment