HasBoxFFI and HasArcFFI aren't great, see bug 1831242 as for examples of
why.
HasArcFFI requires a bit more care, but HasBoxFFI doesn't give us much
benefit. Instead use the same type in the FFI boundary.
Differential Revision: https://phabricator.services.mozilla.com/D177252
`self` keyword specifies to use the element’s own principal box as the
scroll container. If the principal box is not a scroll container, then the
scroll progress timeline is inactive.
Differential Revision: https://phabricator.services.mozilla.com/D175707
This is a tentative way to avoid any timeout in WPT because other
brower vendors may expect getAnimations() works for scroll animations.
The original implementation is error-prone because the user can use the
declarative way to create a CSS animation associated with the document-timeline,
and then changes animation-timeline property to any other scroll-timeline.
If the user calls getAnimations() before changing its style, we still expose
the Animation objects in JS and may crash or have other unexpected bahaviors
if the user tries to access Animation.timeline.
Besides, another benefit of this patch is that we can use other Web Animation
APIs for scroll animations in WPT, e.g. Animation.ready.
Differential Revision: https://phabricator.services.mozilla.com/D176966
Also, I add some similar tests but they don't use Named Timeline Range, which
is not supported by Gecko now (Bug 1824875).
Differential Revision: https://phabricator.services.mozilla.com/D173905
Disable OMTA support for now. We have to make sure what should we do when
the subject is scrolled to "out of view" on the compositor, in Bug 1818346.
And we have to make sure view-timeline-inset animation work well on the
compositor.
Also, update tests,
1) timeline-offset-keyframes-hidden-subject.html, and
2) view-timeline-keyframe-boundary-interpolation.html,
to avoid js error because Gecko doesn't expose Animation object with
scroll-timeline or view-timeline.
And update test, view-timeline-lookup.html, because scroll progress timelines
take precedence over view progress timelines (i.e. choose the matched scroll
progress timeline first), per the spec in
https://drafts.csswg.org/scroll-animations-1/#timeline-scope.
Differential Revision: https://phabricator.services.mozilla.com/D170004
The definition of at-progress-timeline-boundary is updated to use the
unconstructed current timeline if we have, so we update the
implementation as well. It is necessary for view-timeline.
Basically, we use offsets to control the animation progress.
For scroll-timeline, it's simply 0 to the scroll range.
For view-timeline, its progress is between 0% and 100% if the subject element
is in the view. Otherwise, its progress is outside the range.
This patch series doesn't take Named Timeline Range into account because
I expect we will handle them in different bugs, e.g. support the keyframe
selector with `<timeline-range-name>` in Bug 1823509.
So only the basic scenario is implemented:
1. 0% progress represents the position at which the start border edge of the
element’s principal box coincides with the end edge of its view progress
visibility range. (e.g. the top of the subject touches the bottom of
the scrollport, for the vertical axis.)
2. 100% progress represents the position at which the end border edge of the
element’s principal box coincides with the start edge of its view progress
visibility range. (e.g. the bottom of the subject touches the top of
the scrollport, for the vertical axis.)
So basically, it is equal to `cover` range (i.e. we run the animation
when the scrollport covers the subject), per
https://drafts.csswg.org/scroll-animations-1/#valdef-animation-timeline-range-cover
Note: OMTA will be disabled for view timeline in the next patch. So we
implement this only on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D170002
However, We don't lookup the object of view-timeline-name for CSS animations
until we finish its implementation in the patch series.
Note: this patch assumes `view-timeline-inset` is not animatable. We will
fix it in Bug 1817073.
Differential Revision: https://phabricator.services.mozilla.com/D170001
We have an invariant that the mAnimationOrder LinkedList is a subset of the
mAnimations hashset (omitting any animations that are hidden due to
content-visibility). This patch corrects one case where we were incorrectly
inserting an animation into the linked list when it wasn't present in the
hashset (because the animation had completed).
This patch also adds some documentation to mention this invariant, and some
assertions to enforce it in several places.
Differential Revision: https://phabricator.services.mozilla.com/D173333
Specifically:
- We had an obsolete reference to an array (which is now a LinkedList).
- We had an assertion which could benefit from a message for clarity.
- We had an arg whose name was missing the standard "a" prefix.
Differential Revision: https://phabricator.services.mozilla.com/D173332
We are doing the following things here:
1. Rename ScrollTimelineSet to ProgressTimelineScheduler because this
class is used to schedule animations with progress timelines, including
scroll timelines and view timelines.
2. Drop the element property usage and let ElementAnimationData store
ProgressTimelineScheduler.
3. We avoid using the generated content in ScrollTimeline::Scroller.
Instead, we use a pair of Element and PseudoStyleType to represent
ScrollTimeline::Scroller.
We hit the assertion because the generatd content may change and so we
shouldn't use it as the ScrollTimeline::Scroller.
Differential Revision: https://phabricator.services.mozilla.com/D172610
The conversions between an element (including generated content) and the
pair of element and pseudo style type are used frequently, so perhaps it'd
better to factor them out. This patch only moves functions into
AnimationUtils.
FIXME: I suspect Gecko_UpdateAnimations() should early return for the pseudo
elements which we don't support for animations. However, this may cause
some test failures, so we keep the original implementation for now.
Differential Revision: https://phabricator.services.mozilla.com/D159111
Just like how we handle the CSSAnimation and CSSTransition. We use
TimelineCollection to store the named progress timeline objects created
by scroll-timeline-name and view-timeline-name, and reuse
ElementAnimationData to handle the life time of TimelineCollection.
Also, introduce TimelineManager to update timelines generated by CSS.
We add one test which mutates the scroll-timeline-axis to make sure we
restyle the animations associtated with the existing timelines. It will
be passed when we start to use the new framework, in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D169271
ScrollTimeline is inherited from AnimationTimeline, which uses
`nsTHashSet<nsRefPtrHashKey<dom::Animation>>`.
Therefore, its constructor have to know the size of dom::Animation.
In order to avoid build errors in plain mode when adding new files which
include ScrollTimeline.h or AnimationTimeline.h, we have to move its
constructor into the cpp file to make the forward declaration
of dom::Animation work.
Differential Revision: https://phabricator.services.mozilla.com/D170264
So we can reuse it for view timeline. Also, tweak the function name a
little bit so it'd be easier to use template functions.
Differential Revision: https://phabricator.services.mozilla.com/D169270
Computed color values will not be in the correct format, closer to the
one specified by the author. This also means that colors accross the
code are stored now as AbsoluteColor or StyleAbsoluteColor. This allows
color space/gamut information to be available for use.
Some animation related test failures had to be changed, because colors
now has greater precision. Animated a color now causes a lot more
animation updates, which was not initially expected. See the bug for
discussion.
Differential Revision: https://phabricator.services.mozilla.com/D171021
Remove code on bind/unbind that requested a restyle on an unstyled
element, and that canceled that on an unbound element.
Instead, deal with detached nodes in EffectCompositor.
Tweak test restyles since we now expect one restyle as a result of the
initial composing of the animation that before happened eagerly.
Drive-by remove an unused test function in wpt (animationStartsRightNow
is not defined there anyways).
In practice, this makes it consistent with how we handle bind on
elements in shadow trees.
Differential Revision: https://phabricator.services.mozilla.com/D169932
Per spec issue: https://github.com/w3c/csswg-drafts/issues/7401, and the
updated spec words:
If the source of a ScrollTimeline is an element whose principal box does
not exist or is not a scroll container, or if there is no scrollable overflow,
then the ScrollTimeline is inactive.
Besides, it seems we may have other issues related to Bug 1817051, so I
update the wpt to avoid testing the animation sampling times per frame.
Differential Revision: https://phabricator.services.mozilla.com/D169995
This should both be faster and simpler. Also will allow us in the future
to animate more pseudos without having to add a gazillion properties.
I think we should try to clear more stuff (maybe the whole animation
data) on unbind, but that's a bit tangential.
Differential Revision: https://phabricator.services.mozilla.com/D169860
Named scroll progress timelines are declared in the coordinated value list
constructed from the longhands of the scroll-timeline shorthand property,
which form a coordinating list property group with scroll-timeline-name as
the coordinating list base property.
In the meantime, we also update its shorthand to match the current spec.
Differential Revision: https://phabricator.services.mozilla.com/D166596
The spec is still using `Scroll-linked`, so we exclude the change of WPT tests.
I believe WPT will get updates once the spec doc is renamed.
Differential Revision: https://phabricator.services.mozilla.com/D165914
We always use the document timeline of the cloned document, and clone the
paused animation with the preserved progress, even if the original
timeline is null.
Differential Revision: https://phabricator.services.mozilla.com/D164712
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
