Replace the unsafe HashTable<GC::Weak<Animation>> with
GC::WeakHashSet<Animation>, and update all callers to use reference
syntax instead of pointer syntax since the iterator now yields T&.
Remove 11 heavy includes from Document.h that were only needed for
pointer/reference types (already forward-declared in Forward.h), and
extract the nested ViewportClient interface to a standalone header.
This reduces Document.h's recompilation cascade from ~1228 files to
~717 files (42% reduction). Headers like BrowsingContext.h that were
previously transitively included see even larger improvements (from
~1228 down to ~73 dependents).
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
Ensure AccumulatedVisualContext stays synchronized when CSS transform
properties change.
AccumulatedVisualContext copies transform and perspective matrices from
the paintable tree at assignment time. When CSS properties that affect
these matrices change (transform, rotate, scale, translate, perspective,
transform-origin, perspective-origin), we must rebuild the
AccumulatedVisualContext tree to reflect the new values.
This adds a rebuild_accumulated_visual_contexts flag to style
invalidation that triggers a full rebuild during the next paint.
Note: The current invalidation strategy is inefficient - it rebuilds
the entire tree even for single-element transform changes. This could
be improved by patching the AccumulatedVisualContext node in-place with
updated matrices, but only when the transform doesn't transition
from/to none (which would change the tree structure). This optimization
is left for future work.
This adds visit_edges(Cell::Visitor&) methods to various helper structs
that contain GC pointers, and makes sure they are called from owning
GC-heap-allocated objects as needed.
These were found by our Clang plugin after expanding its capabilities.
The added rules will be enforced by CI going forward.
Previously the logic to compute transitions was split across
`ComputedProperties`, `StyleComputer`, and `Animatable` - this commit
consolidates it all in `ComputedProperties`
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)
This was added in Level 2 of the Web Animations spec
In this level of the spec, all time values associated with animations
(including this duration property) are no longer simple numbers but are
instead either percentages or numbers for progress- and time-based
timelines respectively. These values are represented internally by a new
`TimeValue` wrapper struct, and externally (i.e. in JS) as
`CSSNumberish`.
This method did two things:
1) on the base class (`AnimationTimeline`) it was a setter for
`m_current_time` and;
2) on the child classes (e.g. `DocumentTimeline`) it updated the
timeline's current time given a document timestamp
It makes more sense for theses to be distinct methods
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.
Previously we would either parse these as `StyleValueList<T>` or `T`
depending on whether or not there was more than one value, this meant we
always had to handle both cases anywhere we used these values.
Previously we would only update these if:
a) We had a cascaded value for `transition-property`
b) The source of that cascaded value had changed since we last
registered transitions
This meant that there were a lot of changes we didn't apply:
- Changes exclusively to properties other than `transition-property`
(e.g. `transition-duration`, `transition-behavior`, etc)
- Removing the `transition-property` property
- Updating the `transition-property` property in a way that didn't
change it's source (e.g. setting it within inline-style)
Unfortunately this does mean that we now register transitions for all
properties on most elements since "all" is the initial value for
"transition-property" which isn't great for performance, but that can be
looked at in later commits.
Also renames the `clear_transitions` function to clarify this doesn't
affect the associated transition animations.
This fixes an issue where transitions weren't being cancelled when the
relevant transition-property entry was no longer present
This method takes a `TimeStyleValue`, `PercentageStyleValue` or
fully-simplified `CalculatedStyleValue` with a numeric type of time, as
well as a percentage basis and produces the equivalent `Time` value.
This saves us having to reimplement this logic in multiple places
