Bug 188050 – [Web Animations] Implied keyframes should not account for animations on siblings

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

[Antoine Quint]

Created attachment 345842 [details]
Test case

See the attached example, five <div> with the exact same animation applied at different rates as if they had different timing functions.

[Antoine Quint]

We're using the last animated value as the value for the missing 0% keyframe instead of using a snapshot of the unanimated style when the animation started.

[Antoine Quint]

This only happens with the Web Animations API, CSS transitions and CSS animations are unaffected.

[Antoine Quint]

The crux of the problem is that when we have an implied keyframe, such as a missing "from" in the test case, we use the provided pre-blend target style for the current animation, but this style may be affected by prior animations blending before it.

In the case of CSS Animations, it's a little different, since we compute implied keyframes up-front at the time the animations are created. So if the value at creation time and the value at start time are the same, everything looks right, but if the value changes during the delay phase for instance, or even in-flight, then we're wrong too.

[Antoine Quint]

Created attachment 345870 [details]
Test case with changes of underlying value

In the additional test case we show how changing the underlying value during the delay phase and the running phases should alter the course of the animation. In Firefox and Chrome Canary, the changes are accounted for. In WebKit, we completely disregard it.

[Antoine Quint]

Created attachment 345965 [details]
Better test case with dynamic changes of underlying value

[Radar WebKit Bug Importer]

<rdar://problem/71330806>

[Antoine Quint]

I think this bug might have a big impact on WPT where we have the wrong behavior with neutral values.

[Antoine Quint]

The main issue that is causing the original test case to fail is that style is being shared between siblings. The fix for this is to get SharingResolver::resolve() to return null should the element be targeted by an animation that is using implicit keyframes.

I have a work-in-progress fix for this which yields quite a few WPT progressions.

Looking further into implicit keyframes, and although this test does not cover it, I think we are doing the wrong thing in KeyframeEffect::setAnimatedPropertiesInStyle() when picking the style to use if there is no explicit style for the interval keyframes indexes. We should be using the lastStyleChangeEventStyle() here to avoid other animations in the stack producing values being picked up for implicit keyframe styles.

[Antoine Quint]

Created attachment 416191 [details]
Patch

[Antoine Quint]

Created attachment 416232 [details]
Patch

[Antoine Quint]

Created attachment 416238 [details]
Patch for landing

[EWS]

Committed r270837: <https://trac.webkit.org/changeset/270837>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 416238 [details].