ScrollMagic + scrollto + Mac Safari (Retina?) issue

[johnfmorton]

I've seen a particular issue when using ScrollMagic to create parallax animation and also using global navigation to go to particular points on the page. I'm mid development and don't have a code sample to share yet, but 2 "live" examples of this inconsistent behavior are sites referenced on the ScrollMagic home page:

http://www.lempens-design.com/ http://www.viko.net/en/

Using http://www.lempens-design.com/ as the example, when I open this URL on a retina MacBook Pro (brand new machine, OS X 10.10.1, Safari 8.0) and click "Contact" from the global navigation, the page does not always make it to the appropriate area of the page. On occasion, I will see this on a non-retina display when using Safari 8 / OS X 10.10.1, but the problem seems more pronounced on a retina display Mac. I do not see this issue when using Chrome, so I think it's some issue with Safari.

I've been doing tests to try to isolate the issue, and when I'm using GSAP alone, I never see the issue. I've got a CodePen built as a test here: http://codepen.io/johnfmorton/pen/jEqMqK . This does not have ScrollMagic in it yet and the scrollto function in TweenMax executes like I expect.

sample of what I mean by scrollto:

TweenMax.to(window, 2, {scrollTo:{ y:$('#about').offset().top }, ease:Power2.easeOut });

Any thoughts on what's going on with this scenario with MacPro + Safari 8 + retina displays + ScrollMagic + scrollto?

[janpaepke]

I kind of do, because I have experienced this behavior before. The problem though is I couldn't find any other explanation than that it it must be a Safari bug. I reached this conclusion especially because this is the only browser where this happens.

It has even been discussed here multiple times, for example here: https://github.com/janpaepke/ScrollMagic/issues/144 Here's my attempt for an explanation of this behavior:

The TweenMax scrollTo plugin is written in a way, that as soon as the user starts scrolling by himself it will stop the automated scroll, so that the user regains control. If there are animations happening triggering a change of DOM length, this sometimes causes Safari to trigger a scroll event and so wrongly assume, that the user has started scrolling and thus cancels the automated scroll. The only solution I have found thus far is to force the ScrollTo plugin to keep scrolling no matter what, by using the option: autoKill: false.

What is interesting (and what I hadn't noticed before) is the effect it seems to have on this wether its a retina macbook or not. If you find a better explanation or are able to zero in on what is causing this I'd be happy to further investigate.

[johnfmorton]

Thanks, Jan. My guess was that it was Safari throwing a "false" instance of a user scroll event too.

I've been testing this on retina vs. non-retina. I think I've seen it on a non-retina device, but not frequently. My friend who's also looking into the issue hasn't seen it on a non-retina Safari browser.

I'll let you know if I found out more. Thank you.

[janpaepke]

Cool. I'll leave this issue open for now in hopes you find something.

[johnfmorton]

Hi Jan,

I don't have an answer yet, but I can report that using the solution you suggest of "autokill: false" does fix the issue.

TweenMax.to(window, 1, {scrollTo:{y:1000, autoKill:false }, ease:Power2.easeOut});

I will report back if I figure out anything more. I'll go ahead and close this thread for now.

Thank you for your help.

Cheers,

John

[johnfmorton]

After some additional work on the project that instigated my initial post, I kept working on this issue. It turns out the "autoKill: false" did not fix the issue as I thought.

My next solution was to drop the Greensock "scrollTo" plug in entirely and try to use the jQuery version, which would look something like this:

$('html, body').animate({ scrollTop: '1000px' }, {
                duration: 1000,
                complete : function(){
                    // alert('This alert will popup twice. Once for html and once for body.');
                }
            }
        );

Unfortunately, this jQuery solution also exhibits similar problems in Safari (version 8.0.3 as I write this). The scrolling action does take place and seems to get to the target most of the time, but even when it does the animation while the window scrolls, it is jittery as moves into position.

I do not see this jittery animation in Chrome, Firefox or the new Vivaldi browser.

The conclusion I draw from this is that there is no specific problem in ScrollMagic, Greensock's "scrollto" plugin, or even in the jQuery animate scrollTop method. This is a bug in Safari as far as I can tell.

[janpaepke]

Okay, thanks for letting me know... If you have some time left you could check out the latest dev build of ScrollMagic 2.0 and check if the problems persist.

[Paulimausi]

I, too, had problems with smooth scrolling in Safari. After having read this issue I looked into the issue and indeed found that in Safari sometimes unwarranted scroll events get triggered. Fortunately those events have the scrollDirection "PAUSED". As a workaround I use a condition such as the following and I haven't had the problem since.

.on
(
    "enter leave", function( e )
    {
        if (e.scrollDirection != "PAUSED")
        {
            yourTween()
        }
    }
)

P.s. Sorry, it is not working. I still have problems with anchor scrolling in Safari.

P.p.s. I guess I confused events received by Controller and events fired by the Scene. Also scrollDirection "PAUSED" events may be important to restore state after a page reload.

[izumskee]

Hello, guys! I have the same problem too. Is it fixed now? Can you tell me any suggestions how to fix it?

[jyeg]

what's going on with this?

[maryrnd]

Good afternoon! The problem is that the image doesn't open in Safari MacBook Pro and Air, which should be with the scroll animation... On other devices that use Safari, there are no problems..