Before switching CSS animations over to using KeyframeEffectReadOnly::SetFrames
we update the getFrames() API to return the set frame objects (when available)
so that we can test that we are setting the correct frames.
MozReview-Commit-ID: 4SpBRM7Ykyv
In KeyframeEffectReadOnly::ComposeStyle we call StyleAnimationValue::Interpolate
but assume that it always passes. That was true when that code was only used for
CSS animations and CSS transitions since they check that their animation values
can be interpolated before setting up segments.
However, when we set up animations using the Web Animations API we don't perform
that check so it is possible for this call to fail.
In that case, we could just bail, but, according to CSS Transitions we should
apply a 50% switch in this case:
https://drafts.csswg.org/css-transitions/#step-types
(In Web Animations, specifying this is an open issue. See:
https://w3c.github.io/web-animations/#specific-animation-behaviors).
Bug 1064937 tracks doing this in general (we'll likely need to mark various
properties as being no longer unanimatable but instead as supporting discrete
animation) but we can start to introduce it now.
Later in bug 1245748, CSS animations and transitions will likely start using
the same code path as the Web Animations API for setting up keyframes.
As a result, unless we take care to add checks that the values we set are
interpolable, the 50% switch behavior will begin to apply to CSS animations and
transitions too at that point.
Some concerns have been raised about possible web compatibility issues around
the 50% switch behavior (see [1] and [2]). For CSS animations, Chrome already
supports this behavior so it should be ok at least for CSS animations.
When we switch CSS transitions over to the same code path, however, we will need
to be careful to add checks that the transition endpoints are interpolable
(we can investigate introducing this behavior to transitions as a separate bug
that can be easily backed out / preffed off).
Regarding the naming of the test added here, going forward we would like to
restructure the tests under web-platform-tests to better match the structure of
the Web Animations since that seems to be the convention there.
However, this doesn't *quite* match the structure of the spec since there are
upcoming changes to the spec in this area (e.g. renaming animation behaviors to
animation types). However, it should be close enough that we don't have to move
it around too much in future.
[1] https://drafts.csswg.org/css-transitions/#step-types
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1064937#c0
MozReview-Commit-ID: KcxILrckJg9
Specifically, for the 'composite' member on keyframes, we now indicate "use the
composite value specified on the effect" using a missing/undefined 'composite'
member as opposed to a null value.
MozReview-Commit-ID: ZH45GvCTlP
Later in this patch series when we convert tests from web-platform tests to
mochitest-chrome tests, some of the test cases that use zero-length segments
(overlapping keyframes at certain offsets) would trigger failed assertions
in KeyframeEffectReadOnly::ComposeStyle. This is because this method was
originally written with CSS animations in mind where segments cannot be
zero-length. Furthermore, when these same tests cases are run as
web-platform-tests, the failed assertions are not visible.
This patch adjusts the handling of segments to allow zero-length segments and
adds a test to check that the handling matches that defined in Web Animations
which is summarized in the following informative note,
"this procedure permits overlapping keyframes. The behavior is that at the
point of overlap the output value jumps to the value of the last defined
keyframe at that offset. For overlapping frames at 0 or 1, the output value
for iteration progress values less than 0 or greater than or equal to 1 is the
value of the first keyframe or the last keyframe in keyframes
respectively."[1]
[1] https://w3c.github.io/web-animations/#the-effect-value-of-a-keyframe-animation-effect
MozReview-Commit-ID: JdyYbGZtbot
Before we go fixing endTime, we should add tests that activeDuration (which
endTime builds on) is being calculated correctly. (Spoiler: it wasn't, hence
parts 2 and 3 in this patch series.)
This patch just simplifies the keyframe-effect tests so that we don't have to
repeat default values. This makes the tests shorter, easier to scan, and
easier to understand what is being tested.
In some cases we still repeat the default values in order to indicate that
we're testing that we get a particular default value.
