Tested the issue using #65.0.3325.109 on Android Sony Xperia; 4.4.4 and could not reproduce the issue as per the steps mentioned below

Steps:
1. Launched Browser
2. Navigated to https://valentin.ml/misc/chrome-viewport.htm
3. window.innerHeigh value is changing on scrolling the page up and down

@Reporter: Could you please provide the details of your device and if possible attach a screencast as well for further triaging?

Thanks!! 

Yes, window.innerHeight changes for me as well. What I am saying is that there is no way to obtain the CSS viewport height, since window.innerHeight agrees with it only some of the time, and document.documentElement.clientHeight never does.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@Reporter: Could you please help us a with a screencast with the exact issue for better understanding of the issue, that would help us in further triaging of the issue?

Thanks!!

Sorry for not providing a screencast earlier; my phone is currently broken. Here's one I've recorded on someone else's phone now.

In this case, it's the value of 580 pixels that we cannot reliably obtain other than by measuring the height of a 100vh element.

Deleted: chrome-viewport.mp4 115 KB

	chrome-viewport.mp4 115 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue in Android and able to reproduce the issue as per the steps mentioned in comment #2

Chrome versions tested:
65.0.3325.109(Stable), 67.0.3390.1 (Canary)

OS:
Android 4.4.4

Android Devices:
Sony Xperia

Note: This is a Non-Regression issue as same behavior is seen since M58, Untriaged for further inputs.

Please navigate to below link for log's and video--
go/chrome-androidlogs/829356

Thanks!!

Visual viewport is intended to help here:
https://wicg.github.io/visual-viewport/#dom-visualviewport-pageleft

Note that this new value adjusts during pinch zoom as well and the other values don't actually change.

See
http://output.jsbin.com/fujalu

for a modified example of your test case.

Will this API help you achieve what you want?

I'm not sure what information you're trying to get. Is it that you want the full viewport height as-if the URL bar is hidden (even when it's showing)? In that case, it's true that you can't really get at that today. One thing that's been floated is making window.outerHeight include the URL bar height (issue 789380) - though that might not do what you want on desktop since it'll also include the browser toolbars and window border.

Do you have a use-case in mind? These kinds of efforts are best motivated by a real example.

Ping, valentin.huebner@: Can you confirm my interpretation in #11? 

Sorry @bokan for the delay! I was waiting until I have a phone again so that I could test the example from #10. Your interpretation is exactly right: I want to obtain whatever is the css viewport height in pixels, and in Chrome mobile that is the full viewport height as if the URL bar was hidden. Using a modified window.outerHeight as you described it would not work on desktop, as you said.

My use-case was with a similar thing to the little arrow that you can see at google.com/drive on the bottom of the page; I wanted to check the viewport height from javascript to hide the arrow if there was not enough horizontal space. Just generally though it seems that this is such a fundamental value – the height of the actual inner window size that is used for positioning – that there should be a good way to obtain it.

With regards to #10: No, that's not it. At least for me, window.visualViewport.height on the page that you linked is always equal to window.innerHeight, and, in particular, not equal to the CSS viewport height when the URL bar is shown. Also, it didn't seem to change when I zoomed.

The NextAction date has arrived: 2018-05-03

> viewport height from javascript to hide the arrow if there was not enough horizontal space

You mean vertical space, right?

> the height of the actual inner window size that is used for positioning – that there should be a good way to obtain it.

The value described though isn't used for positioning anything. That would be the initial containing block, which intuitively you can think of as the "layout size" of the page. i.e. if you give <html> width: 100%, height: 100%. This doesn't change as the URL bar hides, its height is static and is always the height "as if" the URL bar were showing. You can get this value from document.documentElement.clientHeight.

The one exception here is position: fixed Elements which do get resized. But for that you can use window.innerHeight. That changes as the URL bar hides/shows.

So really the only thing the size you're asking for is used is vh units (i.e. 100vh). While I agree it's a missing feature that we can't get that without instantiating an element - it also seems like the least useful of these kinds of values - documentElement.clientHeight or window.innerHeight is almost always what you want/sufficient. i.e. Couldn't you just use innerHeight for your case? Or clientHeight if you don't want the height to change between URL bar hides.

vertical, that's right, sorry.

Regarding the use case, I should probably have been more specific. I have a large container of fixed (but unknown) height. To indicate to the user that they can scroll down I display the array, with position: absolute, and bottom set in px. However if it overlayed the container, I'd rather not show the array at all, in order not to obscure the content and because it will be clear anyway in this case that the user can scroll down. So I want to obtain the value of 100vh and check whether there is space/need for the arrow. I don't want the arrow to disappear randomly as soon as the user scrolls down (and hides the URL bar), so I need a fixed value. But when I use clientHeight to define a cutoff height it's either wrong by 80px on mobile or on desktop (since I'm comparing it to 100vh).

More generally though: Why does it make sense that in this given situation of a changing viewport height we provide one fixed value to CSS (to prevent jerky layouting), but the other fixed value to javascript? 
It's good that we have a javascript value that is always accurate, and it's good that we have one that doesn't change, but there is no reason why that one shouldn't be the same one that's used for rendering.

> To indicate to the user that they can scroll down I display the array, with position: absolute, and bottom set in px

Hm, I'm still a bit confused as to how the value of 100vh helps here. The page loads with the URL bar showing so wouldn't you want the arrow to appear when the container is larger than the initial viewport height (that is, documentElement.clientHeight)?

> More generally though: Why does it make sense that in this given situation of a changing viewport height we provide one fixed value to CSS (to prevent jerky layouting), but the other fixed value to javascript? 

There's not just 1 fixed value we use for CSS though. See https://output.jsbin.com/ruwivewacu. The orange box is height:100% but if you hide the URL bar you'll see that it's actually smaller than the "100vh size". vh are a more recent addition and comparatively rarely used so that's why the other value is exposed to JS.

Alright then!

I'm going to dup this into issue 789380 since resolving that would fix the issues brought up in this bug. Thanks!