Bug 40564 – Animation: Bad removal from style available wait list

• Component: New Bugs
• Status: NEW

[Joel Rosdahl]

The algorithm in AnimationControllerPrivate::removeFromStyleAvailableWaitList has a bug: prevAnimation is always 0, which means that if animationToRemove is not the first element in m_styleAvailableWaiters, the elements before animationToRemove are lost.

See also the very similar algorithm in AnimationControllerPrivate::removeFromStartTimeResponseWaitList (maybe the code should be refactored?).

Unfortunately, I'm not able to supply a web page that reproduces the bug, but I hope it's obvious enough even without one.

The bug was seen on WebKit Safari-6531.22.2, but exists on current trunk (r61111) as well.

Fix:

Index: WebCore/page/animation/AnimationController.cpp
===================================================================
--- WebCore/page/animation/AnimationController.cpp	(revision 61111)
+++ WebCore/page/animation/AnimationController.cpp	(working copy)
@@ -366,6 +366,7 @@ void AnimationControllerPrivate::removeFromStyleAv
                 
             animationToRemove->setNext(0);
         }
+        prevAnimation = animation;
     }
 }

[Simon Fraser (smfr)]

Joel: we'll need a regression test in order to fix this, so it would greatly help if you could supply a testcase, or at least tell us what your page is doing.

[Joel Rosdahl]

We have a customer that reported a problem with some "graphics garbage". The customer keeps its web pages secret (it's the user interface of a not yet released embedded device), so we don't have access to them. We knew the bug was related to animation in some way since we were given a video showing the problem. When we tried to find the root cause, we made some attempts to create a simple test page that triggered the bug, but we didn't succeed. The bug was instead found by sprinkling the code with log messages and letting the customer reproduce the bug in their environment. The log messages lead us to some areas of the animation code and the fix was then found by code review.

I can't give you the video, but here's an attempt of describing what happened: The page contained a menu and a kind of status bar. When navigating through the menu, there were CSS transitions on several elements (probably about 5-10) comprising the menu and the status bar. One of the elements (the background area of the status bar) did not fade away as it should. When navigating through the menu, it was always the background area element that eventually failed to fade away, but it didn't happen every time. Fading of the background area element was delayed (as in "transition-delay") and fading of some text elements printed on the background area was not delayed.

The problem we saw in the logs was that one of the ImplicitAnimation instances got stuck in the AnimationStateStartWaitStyleAvailable state.

I'm not sure if this was of much help, but I don't have more information. Sorry about that.

[Simon Fraser (smfr)]

Did the content use visibility: hidden?

[Joel Rosdahl]

Yes, that's very likely.

[Simon Fraser (smfr)]

Related to bug 29984 then, also bug 29984.