Jump to content


Seek in IE forwards through ScrollTo

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

On a current scrolling landing page we are building we use a timeline to control animations up and down the page. The scrollTo plugin is used to move the page up and down as the user scrolls. The main navigation at the top then seeks to specific parts of the timeline.


On IE browsers, when we do this seek() or pause(), it quickly flashes through the skipped content. On Chrome or Firefox the timeline advances to that spot with no problems.


This codepen example shows the problem in an abbreviated form. When a click is fired on the link at the top, we utilize a scrollTop function to move the window to the correct position. After two seconds we advance the timeline to the state that would match the window position. In Chrome and Firefox this seek is not noticeable. In IE browsers (tested in IE9, 10, and 11) the content between the top of the page and the new position flashes by. Watch the section h1 carefully to see it.


See the Pen mpAwB by aclabaugh (@aclabaugh) on CodePen


Any ideas on how to stop the seek from showing some of the steps in between a scrollTo tween in IE?

Link to comment
Share on other sites

Hi and welcome to the GreenSock forums.


Any particular reason to use both jQuery and GSAP to do the exact same thing?.


I'm not very clear on what could be happening, but I believe that when you click the element and the scrollTop property is changed. At that point the timeline is at 0 seconds, then a seek method is used to put the timeline in the 3 seconds position and the timeline does exactly that, but keep in mind that when that happens the timeline is at 0 seconds so the timeline jumps to 3 seconds but coming from 0 seconds.I believe that the issue you're experiencing has more to do with JS execution by that particular browser (surprise...surprise!! :D) than a GSAP related issue, which brings back the question, why don't you use a seek() instance to set the timeline's time instead of setting it after the click?, it seems redundant to me.


This code gives no issues:

$("#last").click(function(e) {

I forked your codepen:


See the Pen wDrFH by anon (@anon) on CodePen



Link to comment
Share on other sites

First, you need to understand some of the underlying mechanics at play....


When you create tweens, they don't render immediately. They only render when they're SUPPOSED to render (when they're needed). So in your case, you create a bunch of scheduled tweens and immediately pause the timeline. No problems here. 


Furthermore, when a tween renders for the first time, that is when it records its starting values (and ending values) so that it can interpolate very efficiently between them. 


In order to render sequenced things properly, they must fire in a very precise order. Imagine adding a tween that causes element.width to go to 200 and then another tween that causes element.width to go to 400. If you jump over that first tween (directly to halfway through the 2nd tween), we still have to first render the first tween so that element.width is at 200 before the 2nd tween instantiates, otherwise its starting values would be wrong. 


So back to your example...


When you run tl.seek(3), it has to quickly render the tweens before that place so that everything is proper. Apparently in this case, those older versions of IE have an odd rendering procedure such that even though all of the changes are made in a single "tick", it's still briefly rendering some of those prior tweens as they alter scrollTop to the values you set. In other words, it's quickly doing this:


scrollTop = 100;

scrollTop = 200;

scrollTop = 300; 


Again, those all run almost instantly, and GSAP uses requestAnimationFrame so that updates are rendered exactly as they should, but some older browsers don't recognize requestAnimationFrame, so setTimeout() must be used. That really shouldn't matter anyway, but for whatever reason IE is flashing those changes briefly. This isn't related to GSAP - you'll see the same thing if you use jQuery to set the scrollTop() to two different values, one-after-the-other. Try it yourself. 


Don't worry - there's a pretty easy solution. Just force the timeline to jump to its end and then back to its beginning after you create it so that you force all the tweens to instantiate and record their values. I suppose you might see a brief flash at that point, but when the page loads a lot of people expect something like that. Then, since all the values are instantiated, when you seek(), it should be very fast since there's no extra work involved in instantiation. 


Basically, make this minor change:


That seems to solve the problem in my tests. And for the record, I only saw the flash in IE9 and earlier. 

  • Like 4
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.