Bug 26770 – Transitions fail to run sometimes

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

[Simon Fraser (smfr)]

I'm playing with trying to make opacity transitions only run in hardware when the page is already in hardware, and am running into a bug.

AnimationControllerPrivate has a m_waitingForAResponse member variable, which gets set to 'true' when an animation is going to run in hardware, and give us a callback when it starts.

However, nothing sets this to false, so if you later try and run a software anim in the same frame (since the AnimationController has the same lifetime as the frame), then it never starts.

This may explain some of the transition weirdness.

[Simon Fraser (smfr)]

Is this the right place to clear it?

diff --git a/WebCore/page/animation/AnimationController.cpp b/WebCore/page/animation/AnimationController.cpp
index 58a1f5b..c5bd82a 100644
--- a/WebCore/page/animation/AnimationController.cpp
+++ b/WebCore/page/animation/AnimationController.cpp
@@ -432,6 +432,7 @@ void AnimationControllerPrivate::startTimeResponse(double t)
     
     m_responseWaiters = 0;
     m_lastResponseWaiter = 0;
+    m_waitingForAResponse = false;
 }
 
 AnimationController::AnimationController(Frame* frame)

[Simon Fraser (smfr)]

Actually this works fine as long as receivedStartTimeResponse() gets called. However, if it doesn't for some reason (layer gets blown away?), then that flag gets left set to true.

[Chris Marrin]

You analysis looks right. The problem is what to do if the thing that will trigger the callback never happens. I think if we save a ref to the AnimationBase object that will trigger the callback, and then clear the flag if that object gets destroyed, it will ensure the flag is always in the right state. But in that case, if the flag gets cleared, we will have to make the callback happen right away to get the other animations started. This will destroy sync, but that won't be a big issue in this special case. It will be very rare.

[Simon Fraser (smfr)]

Created attachment 40494 [details]
Possible testcase

Here's a test that I think is showing the same issue. After you run this one test, navigating to another page with animations asserts:
ASSERTION FAILED: !childNeedsStyleRecalc()
(/Volumes/WebKit/WebKit.git/WebCore/dom/Document.cpp:1193 void WebCore::Document::unscheduleStyleRecalc())

[Simon Fraser (smfr)]

The change in comment 1 makes this problem caused by the testcase go away.

[Simon Fraser (smfr)]

There's a reproducible instance of this issue in bug 29984.

[Simon Fraser (smfr)]

Created attachment 41190 [details]
Patch

[Simon Fraser (smfr)]

http://trac.webkit.org/changeset/49633

[Simon Fraser (smfr)]

This broke accelerated transitions in some cases: bug 30453.

[Simon Fraser (smfr)]

Reopening to cover the issues with broken transitions related to visibility:hidden (see also bug 29984).

[Eric Seidel (no email)]

Comment on attachment 41190 [details]
Patch

Clearing mitz's r+ on this obsolete patch.

[Simon Fraser (smfr)]

<rdar://problem/8281319>

[Sam Sneddon [:gsnedders]]

http://trac.webkit.org/changeset/98735
and
http://trac.webkit.org/changeset/98776 

apparently fixed this?

[Radar WebKit Bug Importer]

<rdar://problem/77043647>