Created attachment 91132 [details] Test I hit an assert at WebCore::AnimationBase::freezeAtTime(double) + 158 (AnimationBase.cpp:1381) with the test that will be attached.
m_startTime is still 0 if the transition is in the delay phase.
Looking at the code, this only happens when using the pause API from DRT (or from embedding apps). The play-state property doesn't go through this code path, so there's no way to generate this error with content.
Right, the bug was failed about DRT. This bug prevents me from converting some time-consuming delay-related tests to use the pause API.
Created attachment 100494 [details] Patch
Comment on attachment 100494 [details] Patch This looks good to me. You might want to add an animation test for completeness. I can't wait until this API is improved.
(In reply to comment #5) > (From update of attachment 100494 [details]) > This looks good to me. You might want to add an animation test for completeness. > > I can't wait until this API is improved. Thanks, Dean. I found a problem in following your advice(making an animation test). I'm afraid this patch does not work in an animation case. When an animation is in its delay phase, it should not affect its intrinsic style[1], but this patch is returning the start value of the animation. This is not a regression of this patch, as it is reproducible now. I'd like to fix this problem in another bug because this bug's title is so far away from the above animation bug, if you agree. [1] http://www.w3.org/TR/css3-animations/#animation-behavior-
Comment on attachment 100494 [details] Patch Clearing flags on attachment: 100494 Committed r91187: <http://trac.webkit.org/changeset/91187>
All reviewed patches have been landed. Closing bug.