When constructing an Animation a null should be distinguished
from nothing being passed at all. This is not achieved by
use of our custom ExplicitNull IDL extended attribute.
Instead use the argument count to determine if the argument is
missing, which is a much more common pattern in the codebase.
With monotonically increasing timelines we know that an animation can
never leave the finished state due to timeline changes because the
timeline cannot re-enter the active interval. This is not the case with
non-monotonically increasing timelines (e.g. scroll based timelines)
where this is possible (e.g. by scrolling backwards)
This adds functionality introduced in Web Animations Level 2 around
switching between finite and non-finite (i.e. progress and time-based)
timelines
No functional change as we don't yet have any finite timelines
implemented
Now that we don't always honor requests to add tasks to a queue, we
can't rely on "last added task" as the place to find the task's ID.
Fortunately we can just get it from the task itself.
It is not guaranteed that an animation is ready to run a pending task
when it is scheduled just because it has a timeline, and even if it is,
the current time when scheduling will not necessarily still be correct
when the task is run (e.g. if the timeline changes in the interim).
We had some tests which relied on the previous behavior which have been
updated to await the pending play task
Fixes a crash in the
/web-animations/interfaces/Animatable/animate-no-browsing-context.html
WPT test but it can't be imported since it relies on a python web server
to be running
There are times that we want to update an animation regardless of
whether it's timelines time has changed, for example if an animation
associated with a scroll timeline has a pending task we should run that
on the next update regardless of whether the user has scrolled
An animation with an orphaned owning element should continue to be
ticked by the timeline.
Reverts c8b574e and instead avoids leaking animations by not visiting
`Animation`s from `AnimationTimeline`s.
Fixes a timeout in the imported test
There were a bunch of places that we created
`HTML::TemporaryExecutionContext`s when updating animations in order to
resolve various promises, this worked but as part of the destructor it
would perform a microtask checkpoint which would result in us executing
microtasks earlier than intended, this is solved by instead having a
single temporary execution context for the entire animation update
process which we then destruct at the intended time.
The spec calls for us to use the effective playback rate (i.e. including
any pending updates) when playing an animation.
Fixes a timeout in the newly imported test.
In level 2 of the web animations spec, times are no longer always
measures in milliseconds, they can also be percents when dealing with
progress-based (i.e. scroll-based) timelines.
We don't actually support percent times yet but this change will make it
easier to implement when we do.
Web Animations Level 2 disallows setting some `AnimationEffect` timing
values (start delay, end delay, iteration duration) directly and instead
allows authors to set the specified values which are then normalized
into the actual used values taking into account the type of the
associated timeline (i.e. progress- vs time-based)
From the spec:
> The owning element of a transition refers to the element or
pseudo-element to which the transition-property property was applied
that generated the animation.
https://drafts.csswg.org/css-transitions-2/#owning-element
Previously we only stored the element.
If an animation got to its finished state before its target's computed
properties could be updated, we would end up with invalid styles. Do not
skip finished animations, but prevent effect invalidation on timeline
updates if the animation is already finished.
This fixes the CI flake on WPT test
`css/css-transitions/inherit-height-transition.html`.
Our previous implementation kept track of an AnimationTimeline being
monotonically increasing, by looking at new time values coming in and
setting `m_monotonically_increasing` to `false` whenever a new value
is before the previous known time value.
As far as I can tell, the spec doesn't really ask us to do so: it just
defines 'monotonically increasing' as a property of a timeline, i.e. it
guarantees that returned time values from `::current_time()` are always
greater than or equal to the last returned value.
This fixes a common crash seen when the last render opportunity lies
before the document's origin time, and `::set_current_time()` was
invoked with a negative value. This was especially visible in the
`Text/input/wpt-import/css/cssom/CSSStyleSheet-constructable.html` test.
This fixes an issue where only the last KeyframeEffect applied to an
element would actually have an effect on the computed properties.
It was particularly noticeable when animating a shorthand property like
border-width, since only one of the border edges would have its width
actually animate.
By deferring the invalidation until all animations have been processed,
we also reduce the amount of work that gets done on pages with many
animations/transitions per element. Discord is very fond of this for
example.
Before this change, we were going through the chain of base classes for
each IDL interface object and having them set the prototype to their
prototype.
Instead of doing that, reorder things so that we set the right prototype
immediately in Foo::initialize(), and then don't bother in all the base
class overrides.
This knocks off a ~1% profile item on Speedometer 3.
I agree that the spec definition of this function isn't super clear
about that, but from "Web Animations 1 - 4.5. Animations"[1]:
An animation is a timing node that binds an animation effect child,
called its associated effect, to a timeline parent so that it runs. Both
of these associations are optional and configurable such that an
animation can have no associated effect or timeline at a given moment.
[1]: https://drafts.csswg.org/web-animations-1/#animations
This fixes a bug in `pause()` that canceled the pause task instead
of the play task. This issue prevented the animation from being paused
while a play task is scheduled.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
