I have a tricky problem with Webkit browsers and some custom scrolling behaviour.
On my page, I am detecting scroll, and when it happens, disable the scroll by making the body have overflow:hidden and then do some custom animation logic for the scroll position.
The problem on Webkit browsers (Mac OS) is when I re-enable scroll the native scroll seems to still be easing out, thus moving the page some more in the direction of the initial scroll event, which is undesirable in this case.
Is there a way to disable/reset native scroll or native scroll momentum?
Here is a codepen illustrating the problem. HOWEVER you need to download it as zip and run locally — whatever codepen is doing to the preview container prevents the "native" scroll that is causing the issue. When viewing locally and scrolling "down" what you should see in:
Firefox (the desired behaviour): For 25 frames after the scroll, the scroll position should not move, the page background should be beige. Only when scrolling again should the page animate again
Webkit: After 25 frames after the scroll, you'll see the page flicker white when the animation timeout finishes, and without scrolling anew the "old" native scroll easing seems to still be "ramping down", which triggers the scroll event, and immediately paints the page background beige again. I'd like to avoid this "old native scroll" triggering after I reenable the scrolling.
The solution was to use a different element than body as scroll wrapper. Apparently this behaviour of "resuming" momentum scrolling when re-formatting the body to be scrollable (have overflow) is hard-coded, whereas other scrollable elements do not exhibit this unpredictable side-effect.
Related
I am using a Muuri grid with draggable items. On desktop, users can use the mousewheel to scroll; however, I had to add an event handler to check if the user holds the item for x time, then they can drag the item. If they immediately move a certain distance, it prevents dragging and programmatically scrolls the view with window.scrollTo.
This works fine on Android and Windows touch screens but the screen jumps around on iPhones. Worse on Safari but still occurs on Chrome. I tried using webkit style atrributes that some articles mention for smoother scrolling, used different scroll behaviors, made sure calculations lead to a top, whole number value (only setting top) of 0 or higher, and the only thing that made a difference was setting a delay. A higher delay (100ms) between scrollTo calls seems to resolve it but isn't smooth to the user.
Content for the move event is simply the method call:
window.scrollTo({top: initialTop + yStart - yEnd})
I'm building a full screen slider. The last slide is supposed to have a horizontal scrolling area. I'm using css translations (for a smoother animation) to bring the div inside of the viewport.
For some reason, the scrollbar won't work unless you resize the window.
My guess is that when the scrollable div is created outside of the viewport, it is not rendered by Chrome (for performance reasons?).
Then I guess when you resize, the whole thing gets calculated and redrawn and then it is taken into account.
Here is a JSFiddle that illustrates my problem.
http://fiddle.jshell.net/f3thbjqc/6/show/
Here's a video that illustrates my problem (when I wiggle the mouse is when I try to scroll right, unsuccessfully. Then I resize, and it starts working).
My setup: Mac os High Sierra. Both Chrome 69.0.3497.100, and Safari 11.0.1 (13604.3.5) behave the same, firefox doesn't have the bug somehow
Had a similar problem with the materiallize framework when i was usings tabs and a slider inside. The problem was the slider was not working and after I resized the window it was working perfectly.
Try to fire this event manually when the slider is in view
window.dispatchEvent(new Event('resize'));
I have flicker issues with scrollbar in safari.
when scroller event if fire my page is flick first then set position of scrollbar but i want to remove flickering because it not good for user.
This isn't a specific JS code issue, but more the way iOS deals with JS that is causing more problems on my site than most others.
On iOS only (it doesn't happen on Android) if I'm natively scrolling (up/down) and then try to activate some JS just before the scroll has finished (very quickly) then it completely ignores the JS.
I believe that Apple do this so that the UX always remains priority (don't let any crappy JS slow down the user), but in this case it's just a very simple piece of JS that I want to allow to run.
As an example, if a user is scrolling and then quickly presses a tab at the top of the screen that opens a fixed navigation panel then it won't register if the native scroll is still happening. If they press it again (the scroll has finished) then it works.
I'm also using a JS slider to scroll horizontally through images and if I try to scroll left/right just before the native up/down scroll has finished it sort of jumps and isn't good UX. I think it's prioritising the native scroll but still activating the horizontal scroll with some sort of delay.
It's not a massive problem, but not perfect. If everybody slowly navigated the site and waited for the native scroll to come to a complete stop, it would be great. But of course people won't do this.
I don't think preventing the default behaviour will do anything. I have tried to take over the native scroll before on iOS and I just don't think you can.
I think this may actually happen on many sites. I've just tried to find a good example by visiting stackoverflow.com on an iPhone and if you scroll quickly and then quickly hit a link before the scroll has finished it won't register. I don't think text links are as big a UX issue though, but a horizontal slider and big 'open menu' button at the top are much more likely to be hit quickly before the native scroll has ended (as you don't need to read something before you press it, like with text links).
I have various JS scripts on a site that would benefit from this being improved in iOS, so if I can understand a way around it, why it happens, what is going on, then I can apply individual fixes to each of those scripts.
Thanks.
The problem is not that iOS ignores javascript while scrolling (more precisely, while the scroll momentum is active). The problem is that, while that happens, iOS does not really register the position change of elements on the screen. In fact, if you have a handler attached to the scroll event, it will stop firing the moment you stop touching the screen, and then will fire just once when the scrolling stops.
Consequence? You think you're touching a link, but you aren't. The image on the screen has moved up or down, but, to the broswer, everything is on the same position, so, actually, you aren't touching anything (or are touching something different). I got very annoyed when I found this behaviour because, in my case, my page is full of images that are links to a gallery ... and if you touch them while scrolling, the gallery opens showing you not the image you touched, but another (The one that really was on that position when your fingers stopped touching the screen).
Is there a workaround? The only one that I know of is disabling the scroll momentum, but you lose scrolling performance.
I'm using the relative mode to start and end my animations using the Skrollr plugin (https://github.com/Prinzhorn/skrollr). Everything works great in IE but the animations are occurring early in Safari and Chrome and late in Firefox. I'm using data-bottom as my start point and data-center as my end point. So the animation should start right when the entire element just pops through the bottom of the viewport and should end at the center of the viewport.
Here is the website where you can see the animation occuring under div id="div56709" under the "Why Moms Ministry" section.
http://group.com/womens-ministry/where-moms-connect
Any ideas on why the above issues are occurring would be greatly appreciated.
So the animation should start right when the entire element just pops through the bottom of the viewport
Well, not exactly. data-bottom is short for data-bottom-bottom and means when the bottom of the element is at the bottom of the viewport. What you describe is data-bottom-top.
I tried it in Firefox and Chrome and it looks as expected.
One thing you could try is calling refresh() on window.onload. This will recalculate the relative mode. Maybe when you call init() there are some images not loaded which move the content down (even though you explicitly set width and height on the img elements.)
Edit: In fact, I just verified that this is the problem. You can verify by hitting ctrl+f5 to force a reload. The animation will be off. If you now resize your browser (triggering refresh internally) it works.