Bug 186517 – [Web Animations] Implement "Starting of transitions" section from CSS Transitions

• Status: RESOLVED
• Resolution: FIXED
• Component: Animations

[Antoine Quint]

Implement https://drafts.csswg.org/css-transitions-1/#starting from CSS Transitions.

[Radar WebKit Bug Importer]

<rdar://problem/41000798>

[Antoine Quint]

Created attachment 342939 [details]
Patch

[EWS Watchlist]

Comment on attachment 342939 [details]
Patch

Attachment 342939 [details] did not pass win-ews (win):
Output: http://webkit-queues.webkit.org/results/8232952

New failing tests:
transitions/transition-to-from-auto.html
animations/transition-and-animation-3.html
imported/mozilla/css-transitions/test_animation-ready.html

[EWS Watchlist]

Created attachment 342949 [details]
Archive of layout-test-results from ews200 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews200  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Dean Jackson]

Comment on attachment 342939 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=342939&action=review

> Source/WebCore/animation/AnimationTimeline.cpp:171
> +void AnimationTimeline::updateCSSAnimationsForElement(Element& element, const RenderStyle* currentStyle, const RenderStyle& afterChangeStyle)

Can you keep the currentStyle as a &, since you check for null when you call the method? I guess you still have the case where afterStyleChange has a value but currentStyle doesn't?

[Antoine Quint]

(In reply to Dean Jackson from comment #5)
> Comment on attachment 342939 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=342939&action=review
> 
> > Source/WebCore/animation/AnimationTimeline.cpp:171
> > +void AnimationTimeline::updateCSSAnimationsForElement(Element& element, const RenderStyle* currentStyle, const RenderStyle& afterChangeStyle)
> 
> Can you keep the currentStyle as a &, since you check for null when you call
> the method? I guess you still have the case where afterStyleChange has a
> value but currentStyle doesn't?

Yes, see the call site in TreeResolver::createAnimatedElementUpdate(). CSS Transitions are guaranteed to have before and after styles, but CSS Animations aren't.

[Antoine Quint]

Committed r232946: <https://trac.webkit.org/changeset/232946>