Jump to content
Search Community

display none problem in Timeline

d@ve 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 have an timeline animation that plays when you click the red box. It first sets "display:none" on the #menu div and then continues to animate the #box div. The result is an expanded box with some content in it. To return to the menu you click on the close button on the top right, which will reverse the animation.

 

My problem is that sometimes the animation will break or not complete (I hope I picked the right terms there). So far only three cases have occurred:

 

  1. the animation reverses successfully
  2. on reverse, the #box background will not return to it's initial transparent color, and remains blue; leaving an unwanted background color
  3. on reverse, the #menu display property is not reset to "display:block", instead it remains "display:none"

*note: 2 and 3 occur together, as far as I've seen

 

What I have done to recreate it is just keep refreshing the page, clicking the red box, and exiting the expanded div with the close button. Most of the time it runs fine, but when it doesn't then the user has no access to the menu. Also, the problem sometimes occurs when running the animation over and over, even without a refresh.

 

Any suggestions or insight into what I could be doing wrong?

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

Link to comment
Share on other sites

I just tried it on the links you posted and on both of those the problem occurred on the first try. I refreshed Plunker and the animation ran fine ( anim.play() and anim.reverse() ) the first two times but failed with the same problem the third time around. 

Link to comment
Share on other sites

Maybe you could restructure your animation or your elements?

 

I don't know if this might be any help to you, but I created a similar animation for this discussion. It's uses Angular, but you might be able extract some of what's going on. Basically each element has its own animation, instead of using a master timeline to control everything.

 

http://plnkr.co/edit/cXBEwU?p=preview

Link to comment
Share on other sites

I was trying to avoid separating the animations, but it was also an option if I couldn't figure out what was wrong with my first method. I'll test out both methods and see which one works the best. Thanks again.

Link to comment
Share on other sites

Hi,

 

It took me a little while to see what was going on here.

Blake, thanks for your diligence and D@ve, for your patience.

 

Very helpful to know this appears to be a FireFox-only bug and annoying that it doesn't seem to happen all the time, although I was able to see it happen a few times. Most often the 3rd time after a reload (very strange).

 

The issue appears to be related to the fact that both set() tweens that happen at time(0) do not render their starting values when the timeline is reversed back to a time of 0. 

 

In general set()s are very tricky as they are tweens that have no duration. They technically end as soon as they begin. It can be very tricky to assess whether their start or end values should render based on the time and direction of the playhead in a timeline. Its just very strange that the behavior varies in this use case.

 

By creating a fromTo() tween with a duration, it made it easy for GSAP to know that the starting values should always be rendered at time(0).

 

Another, solution (for now) would be to simply offset the position of the set()s so that they aren't at a time of 0 like so:

 

newAnim.set( $('#menu'), { display: "none"}, 0.001)
  .set( $box, { backgroundColor: 'rgb(62, 132, 200) ' }, 0.001)
 
This should not break: http://codepen.io/anon/pen/myLMPQ
 
With this solution, the playhead is now BEFORE the set()s when you reverse to time(0).
 
It appears you have revealed a bug somewhere. Please give us some time to look into it further.
 
Sorry for the hassle and thanks for your patience.
  • Like 3
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...