Bug 95950 – Animation state machine causes disappearing layers

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Layout and Rendering

[Shawn Singh]

This reproduces on both webkit nightly and chromium.

To reproduce:
  1. go to maps.google.com
  2. enable MapsGL
  3. make sure you are signed in (I could only reproduce this on my gmail account, not my google account)
  4. reload maps.google.com with mapsGL enabled and being signed in --> this is needed to reliably reproduce the problem
  5. click on "my places"

Expected result:
you should see a menu bar on the left-side area, with 4 buttons - "All, Maps, Starred, More"

Actual result:
the bar does not appear at first.   If you resize the window to become small enough, it finally causes something to recompute so that it becomes visible.

example of expected and buggy screenshots can be found at http://code.google.com/p/chromium/issues/detail?id=138213


More debugging details:

The bug occurs because the menu bar buttons have a -webkit-transition animation on it to animate all properties.  In particular, the visibility property has a beginning style as "not visible", and a target style of "visible".  The animation seems to get stuck in the "AnimationStateStartWaitResponse" state, nothing seems to trigger the notification that would let the animations proceed.

[Shawn Singh]

Created attachment 162451 [details]
Hack that fixes the problem, just to illustrate what's going wrong


I'm attaching a patch that fixes the problem, but it's clearly a bad hack, and not the correct solution.  I think the real problem is either a missing notifyAnimationStarted() somewhere, or some bug in the state machine itself.  I'm not clear where to begin looking for either of these possibilities.  When are notifyAnimationStarted() events expected to occur?  What is the relationship between different CSS properties when it comes to being "synchronized" to an accelerated animation?

The comment in AnimationControllerPrivate::addToAnimationsWaitingForStartTimeResponse --->  is this comment accurate?  the function does still add accelerated animations to the list, even though the comment says it does not.  And what is the relationship between all these animations, how do they know they should be synchronized to the same notification event?

It looks like the animations get stuck immediately after the animated dom elements are first initialized... but I'm not 100% sure about that yet.

Suggestions where to continue looking would be appreciated!

[Shawn Singh]

To clarify, the hack is essentially forcing non-accelerated animations to continue without waiting for a notification.  This fixes the problem, but I'm assuming it's not a real correct fix.

[Simon Fraser (smfr)]

A reduced testcase would be helpful.

[Shawn Singh]

(In reply to comment #3)
> A reduced testcase would be helpful.

Making a reduced case has proven to be very elusive =)

One question that would help me make the reduced test case -   What is a valid situation where composited layers are created, but not actually added to the GraphicsLayer tree?  That seems to be what is happening on the google maps page.

[Simon Fraser (smfr)]

That might happen if there are visibility:hidden layers, possibly.

[Shawn Singh]

I wasn't able to create a reduced test case.  In the mean-time, i think pages that had this bug have worked around it, so it no longer reproduces on webkit nightly either.  So I think this is a WONTFIX until we have a more solid repro.

tl;dr - Here's where I left off, for archival purposes:

The root of the issue was that there are (hard-to-reproduce) cases where accelerated animations do not actually start when startAnimation() is called and returns true.  Because of this, all animations waiting to sync get stuck until the accelerated animation finally starts.  

However, I don't think its a bug with accelerated compositor code - this seemed to occur particularly for a composited layer that was not part of the GraphicsLayer tree.  So it did not have the correct delegate/client callbacks to notifyAnimationStarted().

It seems that WebCore is doing something inconsistent to cause this.  Either WebCore needs to never have any orphan composited layers, or the animation system may need to have additional logic that prevents animations from trying to sync with an accelerated animation that might hang.

[Simon Fraser (smfr)]

We've certainly had problem with animations on detached layers before (layers for visibility:hidden).

[Simon Fraser (smfr)]

This might be related: https://bugs.webkit.org/show_bug.cgi?id=26770