Mobile browsers causes jumping due to URL bars etc.

[Florrpan]

Issue: On mobile screens, when the URL bar is hidden or jumps back into view, the content jumps because the height is re-calculated. This is very apparent when using $.scrollify.disable(); for mobile resolutions.

I know, this is not really an issue of Scrollify, but there might be solutions or better implementations, since scrollify is directly working with full height sections. I managed to partially solve the jumping by adding a css transition to the height of the sections, but this won't work with scrollify. I guess it's because scrollify adds PX heights directly in the html document.

There are also several solutions for how to use JS/media query functions to compensate for the URL bar, or to keep the URL bar permanently visible. However; I didn't manage to get any solution working with scrollify. My one solution have been to permanently disable scrollify on mobile to prevent jumping in the content/sections due to the URL bar.

Some discussions and solutions around the issue: (not just background-images) http://stackoverflow.com/questions/24944925/background-image-jumps-when-address-bar-hides-ios-android-mobile-chrome

This really is a problem of modern mobile browsers not respecting content flow or design. I really wish there would be an "easy" way for everyone to use full height sections on mobile w/o jumping, but as it looks now, everyone suffers.

As mentioned in my issue #189 , since snapping causes usability issues on mobiles, I'd like to have an option to disable snapping on lower resolutions so that the user is free to scroll. That brought me to use $.scrollify.disable(); unfortunately it disables snapping on all move actions too, not just the scroll, which in turn disables any navigation set in place using scrollify. When Scrollify snapping is enabled, the URL doesn't get hidden very easily, and often stays there permanently.

I've come a long way with your tool, and I'm really grateful for it. I'm no advanced dev, but I hope that these observations and suggestions can help you and the rest to develop this awesome tool further.

[lukehaas]

Thanks @Florrpan, are you definitely using the latest version of Scrollify? (1.0.8) I made a change recently that meant Scrollify no-longer changes it's scroll position when the page is resized - this seemed to stop the jumping issues when the address bar gets shown/hidden.

[Florrpan]

You're right. I completely missed the update. I'm trying the 1.0.9 right now, awesome!

touchScroll seems to work well on my phone, a nice scrolling experience, that's really awesome! But using touchScroll:false, the URL bar still hides itself when scrolling down and gives a jump in the content(Samsung S5, S6, Chrome and Standard mobile browser). As long as it's "true", and the snapping is active, the bar seems to be visible all the time unless you do a big vertical swipe from the bottom.

Also, it seems that section-names in the URL isn't updated on mobile when touchScroll is set to false, which can cause issues in some scenarios when using "next" or "previous" move action. Example, after navigating to one section with a move action, the URL is updated. Then scrolling 2-3 sections further down, and pressing "next" or "previous", will scroll you right back up to the first section you moved to earlier. Seems that URL isn't updating due to the touch event, might be that it can't see the sections when scrolling freely.

That's what I found right now, I'll play around with this update some more and see if I find something.

Really great work though, I'll make sure to at least buy you a coffee :)

[lukehaas]

When touchScroll is set to false, Scrollify isn't observing the users scrolling so the page scrolls just like any other site. This option is essentially for disabling Scrollify on mobile devices.

Hiding the address bar is default behaviour when you scroll a page on mobile, it's not related to Scrollify.

[Florrpan]

Ok. So the next and previous methods will essentially be a slippery slope on all phones/tablets? I have an interactive menu with next/previous arrows on a design right now, but these will not be very reliable on touch with snapping (touchScroll) turned off.

Am I right when saying, that Scrollify now detects if it is a touch screen? Would it be possible, or a good implementation, to have an option for breakpoints in which the snapping stops and starts?

About the bar: Absolutely, I mentioned that in the original post. Since you mentioned that "this seemed to stop the jumping issues when the address bar gets shown/hidden." I merely confirmed that it didn't. I said that there are methods to conquer it, and it's up to you if you'd want to implement that in your tool or not. Since Scrollify do create full-height sections, a feature to help prevent the jumping would be useful. Example "barVisible: true". It's just a wish from my end. I'm aware that Scrollify is not the culprit here.

I'm sorry if I sound nagging, I'm just a guy with a lots of ideas, nothing more :) I just want to help you improve this tool the way I can!

[lukehaas]

Using the next/previous methods will still snap the user to sections with touchScroll set to false. All setting touchScroll to false is doing is telling Scrollify not to attach touch events - so nothing gets fired when the user scrolls via touch. No detection is needed for Scrollify to do this.

[Florrpan]

Maybe you didn't understand the problem. Since the section-name (EG URL: #section1, #section2, #section3, #section4) is not being updated in the URL when scrolling with the touchScroll:false, next/previous will not work very well. Scrolling to the buttom of the page(#section4) and pressing "next" will take you to #section2, because scrollify don't know that you're on the last section, and thinks #section1 is the section its going to navigate from.

[lukehaas]

That's right, but you could resolve that by using the move method to go to particular sections. For example, the 'next' link at the bottom of #section4 could trigger the move method to go to section 5.

[Florrpan]

I do use move, I also use the next/previous method. But the arrows for next/previous doesn't work on my ipad anymore. But it's no prob, I'll add a JS width breakpoint to sort that out.

[lukehaas]

Are the next/previous arrows browser buttons or are they part of your page?

[Florrpan]

It's a part of the design for a frontpage. The next/previous is hidden on phone size, but visible on tablets.

[mveer-agarwal]

@lukehaas Any update on the issue?

[mariellamarco]

Any update on this issue, I have the same problem in the new Safari's interface, where the URL bar is in the bottom of the page. Thanks.