This is similar to bug 1038488, which did the same for style structs.
This means the entire path from frame to style struct should be
allocated using frame IDs or object IDs.
This also moves those 4 operator new methods to be inline to match the
style of all of the others.
I audited that all the members of these structs are initialized by all
their constructors (see patch 1).
The testcase is a slight simplification of dholbert's testcase 2
(attachment 8456312) in the bug. It fails in the reftest harness
without the patch, and passes in the reftest harness with the patch.
This patch introduces a method GetComputedTiming that calls GetComputedTimingAt
supplying the current time of the animation's timeline.
We still keep the GetComputedTimingAt static method since it is used for
off-main thread animation. Furthermore, we keep the second argument to
GetComputedTiming--the animation's timing properties--since on some occasions we
want to override those properties (ElementPropertyTransition::ValuePortionFor
does this). We could also add another overload that also supplies the
animation's timing properties but that can happen as a separate step.
This patch changes ElementAnimation::GetLocalTimeAt so that instead of taking
the current time as input, it uses the animation's mTimeline member to look up
the current time of the associated timeline. As a result of this, it is possible
to remove a few instances of querying the refresh driver for the current time.
Further instances are removed in subsequent patches.
Furthermore, in order to keep the use of time sources consistent, the mStartTime
of new transitions and animations is initialized with the current time from the
animation's timeline rather than with the latest refresh driver tick.
Since this time could, in future, be null, GetLocalTime(At) is updated to check
for a null start time.
GetLocalTimeAt is also renamed to GetLocalTime in the process.
Once we support arbitrary timelines which can return null current time values,
the local time of an animation can also become null so this patch updates
ElementAnimation::GetLocalTimeAt to return a Nullable<TimeDuration>.
Doing this also allows us to pass the result of GetLocalTimeAt directly to
GetComputedTimingAt.
As part of supporting arbitrary timelines, we'd like to pass null times to the
function that calculates computed timing. Incidentally, this also provides
a means for evaluating calculating timing parameters that are independent of the
current time (currently only the active duration) without requiring a valid
time.
This patch updates the signature of ElementAnimation::GetComputedTimingAt to
take a nullable time duration.
We use the Nullable wrapper to represent null TimeDurations since, unlike,
TimeStamp, TimeDuration does not include a null state.
In order to support arbitrary timelines which may provide a "null" current time,
we need a suitable value to return from GetComputedTimingAt for the animation's
phase when the timeline time is null.
This patch introduces a null animation phase for this purpose.
This patch adds the WebIDL definitions and implementation of
getAnimationPlayers on Element.
It does not include the full definition of AnimationPlayer but only readonly
versions of the currentTime and startTime attributes since these are easy
to implement and enable identifying the different animations that are returned
for the sake of testing.
Web Animations defines getAnimationPlayers as only returning the animations that
are either running or will run in the future (known as "current" animations).
This will likely change since it seems desirable to be able query animations
that have finished but are applying a forwards fill. For now, however, this
patch makes us only return animations that have not finished.
This patch also removes an assertion in ElementAnimation::GetLocalTime that
would fail if called on a finished transition. This assertion is no longer
necessary since an earlier patch in this series removed the overloading of
the animation start time that meant calling this on a finished transition
was unsafe. Furthermore, this assertion, if it were not removed, would fail
if script holds onto a transition and queries its start time after it
completed.
When we expose ElementAnimation objects to script they need to have a parent
object so they can be associated with a Window.
This patch adds a pointer from an ElementAnimation to its AnimationTimeline.
When transitions finish, we keep them around for one additional throttle-able
tick to provide correct behavior for subsequent transitions that may be
triggered. Prior to this patch we did this by overloading the start time of the
animation and setting it to null in this case.
However, if we begin returning ElementAnimation objects to script, script can
hold on to those objects and query their start time even after they are
finished. Therefore we need another means of marking finished transitions that
doesn't clobber the start time field.
This patch introduces a new boolean member for marking such transitions.
While we're touching IsFinishedTransition we also take the chance to tidy up one
of the call sites, namely IsCurrentAt, to make the logic a little easier to
follow.
* Replace png images with svg images for touch caret and selection
carets.
* Fix touch caret is enlarged on high resolution device due to
background-size was not set.
When animation-name does not match a keyframes rule, we should not dispatch
animation events as per:
"Any animation for which both a valid keyframe rule and a non-zero duration
are defined will run and generate events; this includes animations with empty
keyframe rules."
http://dev.w3.org/csswg/css-animations/#events
Since bug 1004377, however, we started dispatching events in this case because
we no longer ignore animations whose set of keyframes is empty.
This patch checks for a matching keyframes rule in BuildAnimations and if one is
not found, no corresponding animation is generated.
