Sticky Navigation: Gap on Scroll Chrome iOS

Hi Fredrik,

This screen gap you see is called elastic scrolling and is a default behavior of browsers in iOS mobile devices.

You can try this CSS and see if it works for the newer iOS versions:

html {
  height: 100%;
  width:100%;
  position: fixed;
  overflow: hidden;
}
body{
   height:100%;
}

If this isn't enough. You'll probably have to create a custom script for this.

Hello Elvin,

Thank you, I will try the CSS :)

But the sticky navigation unhinges from the browser and you can see the background behind it. And this only happens on the front page and the archive page.

From my understanding, it's not default behaviour for the navigation to unhinge itself & I can not find the same behaviour on other live sites that uses position: sticky.

Somethings up.

Can you keep the sticky nav on so we could do more tests?

Also, could you provide the phone model & iOS version you've tested it. Thanks.

By the way, GP theme does "sticky" in a different way. It uses a JS script that applies "position: fixed" when the nav bar isn't in the top of the scroll position.

Hello Elvin,

Sorry, I was debugging some other things. Now the sticky is added again :)

The issue happens on:
iPhone 7
iOS version 14.0 (latest)
iOS Chrome version 85.0.4183.109 (latest)

position sticky works on Safari. But not on Chrome, the unhinging of the navbar happens on the frontpage & product category archive. The single product page works normally.

Custom CSS is turned off & non essential plugins.

PS. Not sure if I can use the built in GP theme sticky, since I need both .main-navigation .secondary-navigation to be sticky.

Hi there,

i am not seeing the issue on my iPhone 7 - but i haven't updated to iOS v14 yet.
What happens if you remove the sticky CSS from the Secondary Nav ?

Hello David,

I removed the sticky CSS for the Secondary Nav, one thing to note is that I turned off the .secondary-navigation for mobile, so it was never on in the first place :)

The result seems to be the same, see video:

Screen Cap

You can see the sticky unhinges on the frontpage & on the product archive page on scroll. But the single product page works as expected when scrolling.

*Edit

So if I replace the front page image grid (Generate Blocks) with plain text the problem disappears & sticky starts working as expected on the front page.

It still persists on the product archive page but this is also based on CSS Grid (woo columns).

So my guess is that it has something to do with the CSS Grid & I don't think the Single Product page uses grid in that way, one reason that page never had the issue in the first place.

Let me know :)

GenerateBlocks uses flexbox - no CSS Grid (which the product archive does use).

I don't have an iPhone to test on, but this just looks like the browser bar shrinking/growing causing a slight gap for a moment. It's strange that it only happens on some pages.

If you add a regular page with nothing but static content, does it still happen?

Alright :) then we can rule out CSS Grid.

So doing some more testing, it looks like it depends on the length of the page & this hides the initial problem.

When you add long lengths of text, stack many image galleries on the page or add many products in the product archive it looks like it resolves itself. Until you scroll down to the end of the page. Then it happens again. So it happens on each page but it's only noticeable when you get to the footer/end of the page.

Each time you scroll down to the footer & the browser bar is shrunk, scrolling up leads to the nav bar unhinging itself. And why this happens is a big question mark.

I think this may be just how fixed elements work with the shrinking of the browser bar in iOS. I don't believe there's anything code-wise we can do to fix it, especially if position: sticky doesn't fix it (as that's native to the browser).

Hello Tom,

Looks that way for now :) I find that using something like Elvin suggested works at least to some extent.

I got some insights from Chromium engineer David Bokand, https://github.com/bokand/URLBarSizing

" iOS Chrome uses a WebView control provided by the OS. When the URL bar changes state, Chrome needs to resize the WebView. On Android and in Safari, the browser can resize the page layout but treat elements like fixed and sticky especially by smoothly animating them with the URL bar. The iOS WebView doesn't provide that level of granular control to the embedding app. The only way the browser could do this is resizing the entire WebView smoothly (i.e. 60 times per second) as the URL bar animates in/out. This would be bad for performance since we'd have to perform layout and fire resize event handlers that often.

URL bar behaviour is quite nuanced and unfortunately, the iOS WebView doesn't provide all the necessary information and APIs to fully achieve equivalent behaviours: e.g. see https://crbug.com/720048 "

Thanks for the additional info on the issue - good to know! :)