We're failing one last test in web-animations/animation-model/keyframe-effects/effect-value-iteration-composite-operation.html: test(t => { const div = createDiv(t); const anim = div.animate({ opacity: [0, 0.4] }, { duration: 100 * MS_PER_SEC, easing: 'linear', iterations: 10, iterationComposite: 'accumulate' }); anim.pause(); anim.currentTime = anim.effect.getComputedTiming().duration / 2; assert_equals(getComputedStyle(div).opacity, '0.2', 'Animated opacity style at 50s of the first iteration'); anim.currentTime = anim.effect.getComputedTiming().duration * 2; assert_equals(getComputedStyle(div).opacity, '0.8', 'Animated opacity style at 0s of the third iteration'); anim.currentTime += anim.effect.getComputedTiming().duration / 2; assert_equals(getComputedStyle(div).opacity, '1', // (0.8 + 1.2) * 0.5 'Animated opacity style at 50s of the third iteration'); }, 'iteration composition of opacity animation'); We fail the final assertion because we actually blending between 0.8 and 1.0. Indeed, when we compute the from/to keyframe when iterationComposite is set to "accumulate", we go through the blending code and this will lead to the RenderStyle methods to be called to set the property value on the keyframe styles, which clamps the values to the valid [0-1] range, thus not allowing us to set 1.2. For types that are backed by numeric values that don't require special accumulation blending rules, we should use some simple math to implement iterationComposite instead of going through the blending code.
Pull request: https://github.com/WebKit/WebKit/pull/6811
Pull request: https://github.com/WebKit/WebKit/pull/6812
(In reply to Antoine Quint from comment #2) > Pull request: https://github.com/WebKit/WebKit/pull/6812 This was posted here by error, that PR is for bug 246851.
Committed 257033@main (f0e70ac5078d): <https://commits.webkit.org/257033@main> Reviewed commits have been landed. Closing PR #6811 and removing active labels.
<rdar://problem/102680710>