Bug 26770

Summary:

Transitions fail to run sometimes

Product:

WebKit

Reporter:

Simon Fraser (smfr) <simon.fraser>

Component:

Layout and Rendering

Assignee:

Simon Fraser (smfr) <simon.fraser>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

cmarrin, eoconnor, gsnedders, menard, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

Mac

OS:

OS X 10.5

Bug Depends on:

Bug Blocks:

93136

Attachments:

Description	Flags
Possible testcase	none
Patch	none

Simon Fraser (smfr)

Reported 2009-06-26 22:44:57 PDT

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.

Attachments
Possible testcase (1.35 KB, text/html) 2009-10-01 21:23 PDT, Simon Fraser (smfr)	no flags	Details
Patch (10.98 KB, patch) 2009-10-14 14:46 PDT, Simon Fraser (smfr)	no flags	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Simon Fraser (smfr)

Comment 1 2009-06-26 22:47:14 PDT

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)

Comment 2 2009-06-26 22:56:02 PDT

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

Comment 3 2009-06-27 06:32:23 PDT

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)

Comment 4 2009-10-01 21:23:49 PDT

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)

Comment 5 2009-10-01 21:38:43 PDT

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

Simon Fraser (smfr)

Comment 6 2009-10-06 21:58:27 PDT

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

Simon Fraser (smfr)

Comment 7 2009-10-14 14:46:48 PDT

Created attachment 41190 [details] Patch

Simon Fraser (smfr)

Comment 8 2009-10-15 09:53:11 PDT

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