Bug 186517

Summary: [Web Animations] Implement "Starting of transitions" section from CSS Transitions
Product: WebKit Reporter: Antoine Quint <graouts>
Component: AnimationsAssignee: Antoine Quint <graouts>
Status: RESOLVED FIXED    
Severity: Normal CC: dino, dstockwell, ews-watchlist, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch
dino: review+, ews-watchlist: commit-queue-
Archive of layout-test-results from ews200 for win-future none

Antoine Quint
Reported 2018-06-11 05:11:48 PDT
Implement https://drafts.csswg.org/css-transitions-1/#starting from CSS Transitions.
Attachments
Patch (82.95 KB, patch)
2018-06-18 08:50 PDT, Antoine Quint 		dino: review+
ews-watchlist: commit-queue-
DetailsFormatted DiffDiff
Archive of layout-test-results from ews200 for win-future (12.85 MB, application/zip)
2018-06-18 10:30 PDT, EWS Watchlist 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2018-06-11 05:12:01 PDT
<rdar://problem/41000798>
Antoine Quint
Comment 2 2018-06-18 08:50:21 PDT
Created attachment 342939 [details] Patch
EWS Watchlist
Comment 3 2018-06-18 10:30:30 PDT
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
Comment 4 2018-06-18 10:30:41 PDT
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 5 2018-06-18 11:41:15 PDT
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
Comment 6 2018-06-18 14:19:42 PDT
(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
Comment 7 2018-06-18 14:20:55 PDT
Committed r232946: <https://trac.webkit.org/changeset/232946>
Note You need to log in before you can comment on or make changes to this bug.