Android Chrome, UI bar dissappears as user scrolls down leaving gap when moving page

[samuelgoddard]

Hard one to explain, but I have a bug on Android Chrome when using this library with Gatsby, everything works fine but if I navigate to a page that isn't locked to 100vh, scroll down, the android UI bar at the bottom on the screen dissappears, when I nav back to another page from my fixed header, the 100vh page is calculated with the OS UI bar even though it isn't there, leaving a gap at the bottom.

An example can be seen here - https://prb-architects.netlify.app/ - if you navigate to a project from the carousel on the home page, scroll down, then click back in the fixed header at the top, you'll see the bug.

Is there any way anyone knows a workaround for this? It's fine in every mobile browser except Chrome Android

Thanks in advance,
Sam

[mvasin]

Hi Sam! We rely on document.documentElement.clientHeight || window.innerHeight to determine the height. Could you try to debug these values to see if it's a browser issue or the app issue? A link to a minimal reproduction (as little code and dependencies as possible just to reproduce the issue) would also help.

[sandren]

I've encountered this behavior as well, but I think it is preferable to have a small gap where the address bar used to be than for the initial content to be completely out of view.

You can use this demo created by the Chromium team to help troubleshoot issues with document.documentElement.clientHeight values. Alternatively you could change the position of the element you are trying to resize to fixed, which will make it responsive to viewport changes, but that might not be what you want either.

[Blagoj5]

I'm having the same exact problem for some reason it leaves a gap when i scroll up (when the navbar from chrome disappears). And my element is set to fixed with: top: 0 left:0 bottom: 0 properties (btw im doing a side drawer)

[kirill-kruchkov]

Hello! When I faced a similar issue, I've done some research and found that this trick suggests to rely purely on window.innerHeight. @mvasin is there any reason I'm missing to prefer documentElement.clientHeight over window.innerHeight?

[rinorzek]

+1 , any updates?

[davilatk]

+1 , any updates?

[mvasin]

Hi all,

I did some testing on BrowserStack (thanks for OSS sponsorship, BrowserStack!), window.innerHeight does look superior to documentElement.clientHeight - I only noticed document.documentElement.clientHeight being updated on after rotation, while window.innerHeight is updated on the URL bar height change.

It's a bit bizarre to change it from document.documentElement.clientHeight to window.innerHeight (see #22) and now back (in #74), but seems like going for document.documentElement.clientHeight was a mistake.

I published #74 as [email protected], please try it out.

[mvasin]

I received a few comments confirming that swapping document.documentElement.clientHeight for window.innerHeight works well, so I published version 0.7.0 with the update. Closing the issue for now.