Jump to content
Search Community

ScrollTo bug in 1.8.2 in Safari 6.0.2 & Mountain Lion

sibhod test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I've been working on a project for several months now, and had been using an older version of GSAP for animations, largely to scroll the site up and down to specific sections when the user clicks the navigation. I recently updated from beta 1.5 to the latest ( 1.8.2 ) and noticed that the site no longer scrolled properly: the scroll animation will start and get about 20-50px and just stop.

 

This only happens in Safari/ML 10.8.2. I used BrowserStack to version test, and Safari 6.0.2 in Lion works just fine. 

 

To debug, I set an onUpdate function to log the $( window ).scrollTop(), and it seems as if the tween fails at setting the window's scroll, but continues to run fine:

Image%202013.02.06%2011:34:20%20AM.png

 

I was able to solve my problem by just reverting back to 1.5, but I wanted to send a bug report.

Link to comment
Share on other sites

Interesting. I just tested in OS X 10.8.2 in Safari 6.0.2 and it seemed to work great. Can you post an example file that demonstrates the issue? 

 

The thing that likely changed between your old version and the newer one is that inside ScrollToPlugin, we added code to record the scroll position that we're setting internally and then comparing it each render with where it is then so that we can sense if it changed because if it did, that most likely means that the user tried to manually scroll, so we should honor that. It's really annoying as a user to try scrolling a window only to have code FORCE the window to keep scrolling somewhere else. It was our attempt to be "smart" and improve the user experience for you. However, some versions of Safari have a bug that cause it to report the value incorrectly in certain situations! So, for example, the ScrollToPlugin may set the value to 300 and then check and Safari says it is at 0! Or it'll completely ignore the attempt to set it for a frame or two. Then the plugin checks and discovers it's different and assumes the user must have scrolled.

 

See the challenge? 

 

So to be clear, the code that most likely has the "problem" is in ScrollToPlugin. I'd definitely recommend updating the rest of your core files to 1.8.2 even if you use the older version of ScrollToPlugin. And remember, that old ScrollToPlugin will keep going even if the user tries to scroll - that's most likely why it works for you - it doesn't have any code that's auto-canceling when it senses a change. 

 

Again, if you could post a very simple example that clearly demonstrates the issue, that'd be a big help. I couldn't reproduce the problem on my end, but I'm sure I'm doing something different than you are. 

Link to comment
Share on other sites

Thanks for the reply!

 

I will try to throw together a demo of the bug in action, although if it's not repeatable and well contained to just my one implementation  on one specific os/browser then it's probably not a big deal. 

 

It wasn't looking like the tween was getting killed by a user scroll, because the 'onUpdate' log was still reporting for the full duration of the tween even after it stopped scrolling the page. I'll see if just changing the autoKill prop fixes it too though.

 

Thanks again!

Link to comment
Share on other sites

  • 2 weeks later...

It turns out reverting to the old version was causing even more errors and issues that I had missed at first so I ended up just updating the project to the latest GSAP version, and now am hoping to solve this ML/Safari issue that persists once again.

 

I created a demo page, but much to my chagrin it works fine: scrollToTest.html

 

The site is currently live (with the bug :-/ ) at vasonanetworks.com

 

I doubt just looking at it will help, but I have a dev version I can drop in some traces or logs if you happen to have any ideas what Safari in ML's problem seems to be.

Link to comment
Share on other sites

We'd be happy to help, but it's important that we're able to see a simplified example. It can get pretty time-consuming and messy when we need to wade into someone else's production code and try to wrap our heads around all the different moving parts, intended functionality, and how different parts of the code interact with each other and then isolate the issue and identify exactly what's causing it. 

 

No offense to you at all - it's a really nice site and I have no doubt you guys are very solid developers. That's obvious from your work. It's just that in our experience, the vast majority of the time when we roll up our sleeves and dig into someone else's production code where they think there's a GSAP bug, it ends up being something else in their code. (Again, that very well may not be the case here). It's just really hard to provide free consulting services like that when it eats up so much time and can't be replicated in a simpler file. 

 

If you still need help and can't provide a simplified example, we do offer consulting services for a fee (we can chat offline about that, maybe via PM or e-mail). And if it does end up being a GSAP bug, we don't charge a dime. We definitely want to squash any bugs in our stuff.

 

And by the way, you're using the latest version of the ScrollToPlugin as well, right? You can set the autoKill property to false if you want to make sure it won't automatically kill itself when it senses a change in the scroll position that it didn't make itself. 

  • Like 1
Link to comment
Share on other sites

Oh I'm sorry I wasn't expecting you to dig through and fix the site for me! I just wanted to show you an example of the bug in action, in the long shot that seeing it in action could possibly shed some light. Judging from the simple demo working fine in the offending browser, I have no doubt the issue is on my end. 

 

You're offering amazing support for an already generous product and I really appreciate it. I'll continue to work on the issue and in the off chance that it does end up being a GSAP bug I'll be sure to let you know.

  • Like 1
Link to comment
Share on other sites

  • 10 months later...

 

Please provide a reduced test case that clearly illustrates the issue so that we can effectively assist you.

 

 

Here's a test sample: http://maxim.comze.com

You can download the zipped files here: http://maxim.comze.com/test.zip

 

Try clicking the buttons on the left, go through them one by one. When the buttons goes black it means it reached the scroll target. In Chrome and others it works fine, in Safari it has an issue, it keeps pausing before reaching the target.

Link to comment
Share on other sites

Hi,

 

I believe the issue is related to how often scroll events fire and how much code you are running repeatedly on each event.

 

I made a little video to explain this is more detail:

http://greensock.com/temp/scrollproblems.mov

 

In addition I think the following resources will help

 

Why using scroll events can be bad:

http://forums.greensock.com/topic/8307-page-scroll-event-vs-ticker/#entry32173

 

Example of changing text based on scroll position

http://codepen.io/bassta/pen/eIyrd

You will see that the setHeader() function is only called when necessary

 

Also, I'm pretty sure one of the guys around here (bassta,jamie or rodrigo) has built a codepen that makes use of setTimeOut as opposed to every scroll event for running some conditional logic. Perhaps someone will chime in with some more tips on making your code more efficient.

  • Like 2
Link to comment
Share on other sites

I've been tweaking and reorganise the code and it's much better now in Safari, but still at some places the browser fps has to drop to 30, and when that happens, in Safari the GSAP scrollTo function dies. I resorted to use jQuerys ScrollTop, as it doesn't die in the middle of the scroll regardless of the FPS or how slow the scroll duration is. I also noticed the results are better when I strategically used the killTweensOf or killDelayedCallsTo on tweens that are causing scrollTo to hang, regardless I think scrollTo should never die in the middle of a scroll because of low fps.

 

Also I found this very handy code which helps control the FPS: http://benalman.com/projects/jquery-throttle-debounce-plugin/

 

I can use the above plugin along with GSAP scrollTo and it  works fine, but for now I'll stay safe and stick to jQuery scrollTop.

Link to comment
Share on other sites

I suspect you're running into something with the autoKill feature which automatically tries to sense if you (or any other process) altered the scroll position outside of the tween (like if the user flicks their scrollwheel in the middle of the tween) and if so, it kills that part of the tween. You can disable this by passing autoKill:false into the tween. 

TweenLite.to(window, 1, {scrollTo:{y:300, autoKill:false}});

Again, that feature is intended to HELP you, but Safari seems to have some bugs in the way it handles scrolling at times. 

  • Like 5
Link to comment
Share on other sites

Ah, here's the scroll throttling code Carl mentioned. You could also utilise the excellent throttle-debounce plugin by Ben Alman for this.

 

Debounce: Wait until scrolling is complete to run code:

var scrollTimeout;

$(window).on('scroll', onscroll);

function onscroll(e) {
  clearTimeout(scrollTimeout);
  scrollTimeout = setTimeout(scrollcomplete, 200);
}
function scrollcomplete() {
  // code to run after scrolling here
}

Throttle: Run code throughout scrolling, but at a lower rate than the scroll events:

var scrollTimeout,
    scrollactive = false;

$(window).on('scroll', onscroll);

function onscroll(e) {
  if (!scrollactive) {
    scrollupdate();
    
    // throttle the next scrollupdate
    scrollactive = true;
    clearTimeout(scrollTimeout);
    scrollTimeout = setTimeout(function() { scrollactive = false; }, 200);
  }
}
function scrollupdate() {
  // code to run during scrolling here
}

Actually, it looks like you are doing something similar for your resize events already...

  • Like 2
Link to comment
Share on other sites

Thank you. So I guess autoKill was true by default.

 

I suspect you're running into something with the autoKill feature which automatically tries to sense if you (or any other process) altered the scroll position outside of the tween (like if the user flicks their scrollwheel in the middle of the tween) and if so, it kills that part of the tween. You can disable this by passing autoKill:false into the tween. 

TweenLite.to(window, 1, {scrollTo:{y:300, autoKill:false}});

Again, that feature is intended to HELP you, but Safari seems to have some bugs in the way it handles scrolling at times. 

Link to comment
Share on other sites

Actually, it looks like you are doing something similar for your resize events already...

 

 

Similar but not the same, for the resize, it basically saves the window size at the beginning from the time the page loaded, and after resize is finished it compares it to the window size then, if both are bigger or smaller than the set margin then reload the page. I later added the debounce code of Ben Alman (above) to the checkWidth() function, so it only checks it at the end of the resize.

Link to comment
Share on other sites

Jamie,

 

Thanks for providing both those snippets.

 

I've created 2 barebones codepens in case folks would like to see them in action.

 

Scroll throttled:

http://codepen.io/GreenSock/pen/ulrJD

 

Wait til scroll complete:

http://codepen.io/GreenSock/pen/AwHmy

 

I'm sure these examples will prove quite helpful to myself and others. Thanks a bunch!

  • Like 2
Link to comment
Share on other sites

  • 3 months later...

I'm having the same problem in Safari 7.0.3. I managed to somewhat fix it by setting "autoKill", which lets the animation finish but it ends up being very jitterish.  As if something's interrupting the scroll animation every couple of frames - despite there being no scroll listeners or anything like that.

Link to comment
Share on other sites

  • 8 months later...

Hi, i just bumped into this "issue". No problems on safari 6-, but after that it's just madness. I've tried disabling autoKill, but it just gets worse. It's like there's an extra scroll input mid animation which triggers the autoKill. I just can't get my head around from where is this being triggered. The only thing I can say it's that before stoping the previous y value stored is way bigger than the current y value, so the yDif its going to be much larger than the 7px threshold.

Again this is only true for safari 6+. It could be frame related.

Thanks for any help or light shed on this matter,

Rui

Link to comment
Share on other sites

The issue with this is that, you then should work around the user scrolling to stop that animation, in order to prevent unwanted jittering.
Also I believe that :

$('html, body').animate({ scrollTop:0});

double triggers in some cases. Correct me if i'm wrong.

But for the time being it might be a solution, anyway I would like to try and get the plugin to work with latest safari correctly.

Edited by RBarros
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...