Bug 190257 - [Web Animations] REGRESSION: setting 'animation-name: none' after a 'fill: forwards' animation has completed does not revert to the unanimated style
Summary: [Web Animations] REGRESSION: setting 'animation-name: none' after a 'fill: fo...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Animations (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Antoine Quint
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-10-03 12:06 PDT by Antoine Quint
Modified: 2018-10-06 07:54 PDT (History)
8 users (show)

See Also:


Attachments
Patch (5.90 KB, patch)
2018-10-03 12:13 PDT, Antoine Quint
no flags Details | Formatted Diff | Diff
Patch (10.11 KB, patch)
2018-10-06 07:51 PDT, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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...