Bug 190257

Summary: [Web Animations] REGRESSION: setting 'animation-name: none' after a 'fill: forwards' animation has completed does not revert to the unanimated style
Product: WebKit Reporter: Antoine Quint <graouts>
Component: AnimationsAssignee: Antoine Quint <graouts>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, cgarcia, dino, ews-watchlist, ryanhaddad, tsavell, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=190307
Attachments:
Description Flags
Patch
none
Patch none

Description Antoine Quint 2018-10-03 12:06:40 PDT
Setting 'animation-name: none' after a 'fill: forwards' animation has completed does not revert to the unanimated style.
Comment 1 Antoine Quint 2018-10-03 12:06:54 PDT
<rdar://problem/41341473>
Comment 2 Antoine Quint 2018-10-03 12:13:52 PDT
Created attachment 351541 [details]
Patch
Comment 3 Dean Jackson 2018-10-03 12:17:34 PDT
Comment on attachment 351541 [details]
Patch

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

> Source/WebCore/animation/AnimationTimeline.cpp:479
>      ASSERT(animation);

If this is always non-null, can the parameter be a Ref<>?

> Source/WebCore/animation/DeclarativeAnimation.h:45
> +    Element& target() const { return m_target; }

Can this be const Element&?

> LayoutTests/animations/animation-fill-forwards-removal.html:20
> +        assert_equals(getComputedStyle(target).marginLeft, "100px", "The target element has style values from the final keyframe of its animation.");

Have events always fired after we update the final style? I guess so.
Comment 4 Antoine Quint 2018-10-03 12:21:31 PDT
(In reply to Dean Jackson from comment #3)
> Comment on attachment 351541 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=351541&action=review
> 
> > Source/WebCore/animation/AnimationTimeline.cpp:479
> >      ASSERT(animation);
> 
> If this is always non-null, can the parameter be a Ref<>?

I'll look into it.

> > Source/WebCore/animation/DeclarativeAnimation.h:45
> > +    Element& target() const { return m_target; }
> 
> Can this be const Element&?

I'll look into it.

> > LayoutTests/animations/animation-fill-forwards-removal.html:20
> > +        assert_equals(getComputedStyle(target).marginLeft, "100px", "The target element has style values from the final keyframe of its animation.");
> 
> Have events always fired after we update the final style? I guess so.

Yes.
Comment 5 Antoine Quint 2018-10-03 13:54:24 PDT
Committed r236809: <https://trac.webkit.org/changeset/236809>
Comment 6 Truitt Savell 2018-10-04 16:02:26 PDT
Looks like after https://trac.webkit.org/changeset/236809/webkit 

imported/mozilla/css-transitions/test_event-dispatch.html has become a flakey timeout. 

Confirmed using command:
run-webkit-tests --root testbuild-236809 imported/mozilla/css-transitions/test_event-dispatch.html --iterations 5000 -f

running this on 236809 leads to a low number of timeout, running it on the previous built revision 236806 yields no timeouts.

History:
https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=imported%2Fmozilla%2Fcss-transitions%2Ftest_event-dispatch.html
Comment 7 youenn fablet 2018-10-06 07:51:27 PDT
Reopening to attach new patch.
Comment 8 youenn fablet 2018-10-06 07:51:28 PDT
Created attachment 351723 [details]
Patch
Comment 9 youenn fablet 2018-10-06 07:54:32 PDT
(In reply to youenn fablet from comment #8)
> Created attachment 351723 [details]
> Patch

Bad upload...