[Resolved] Sticky Navigation: Gap on Scroll Chrome iOS

Home Forums Support Sticky Navigation: Gap on Scroll Chrome iOS

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #1451416
    Fredrik

    Hello,

    Been trying to fix a gap that occurs when scrolling on Chrome/iOS, with sticky navigation.

    	body {
    		overscroll-behavior-y: none;
    	}
    	
    	.main-navigation {
    		position: -webkit-sticky;
    		position: sticky;
    		top: 0px;
    	}
    	
    	.secondary-navigation {
    		position: -webkit-sticky;
    		position: sticky;
    		top: 60px;
    	}

    Here is a mobile screen cap of the issue (extreme slow mo)
    https://prnt.sc/ukpq45

    Any way to fix this this strange gap? overscroll-behavior is not supported on iOS.

    #1451566
    Elvin
    Customer Support

    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.

    A wise man once said:
    "Have you cleared your cache?"

    #1451855
    Fredrik

    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.

    #1452879
    Elvin
    Customer Support

    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.

    A wise man once said:
    "Have you cleared your cache?"

    #1456080
    Fredrik

    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.

    #1456504
    David
    Staff
    Customer Support

    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 ?

    #1456638
    Fredrik

    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.

    #1456668
    Fredrik

    *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 πŸ™‚

    #1457396
    Tom
    Lead Developer
    Lead Developer

    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?

    #1457453
    Fredrik

    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.

    #1458803
    Tom
    Lead Developer
    Lead Developer

    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).

    #1460112
    Fredrik

    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

    #1460292
    Tom
    Lead Developer
    Lead Developer

    Thanks for the additional info on the issue – good to know! πŸ™‚

Viewing 13 posts - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.