Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
We keep a set of properties which are running on the
`CascadeLevel::Animations`, to make sure we compose the correct properties
for the rule on Animations/Transitions cascade level.
In other words, without this patch, we may accidentally compose an
animation rule for `CascadeLevel::Animations` (from the KeyframeEffect of
the existing transition), even if we don't have any running animations,
if this transition property is a custom property.
The resolution is to use `AnimatedPropertyIDSet`, for
`mPropertiesForAnimationsLevel`, so we can skip the custom properties which
shouldn't belong to Animations cascade level when composing them.
Note that we don't change the logic, and we are still using
`nsCSSPropertyIDSet` for `EffectSet::mPropertiesWithImportantRules`
because compositor animations don't allow custom properties now.
(This could be a future work I guess, if we are using custom property
values for opacity, translate, rotate, scale, etc.)
Also, I noticed the subtest, "No transition when removing @property rule",
is similar to the testcase in this bug, and so it got passed as well.
Differential Revision: https://phabricator.services.mozilla.com/D210589
We had a test for this but it didn't get to the buggy line because the
opacity animation in the test started at 1. Fixed, and also added a test
for a compositor animation.
Differential Revision: https://phabricator.services.mozilla.com/D201355
The check is not fully correct as per the comment (bug 779598 removed
the preserve-3d check).
I went through the relevant bugs and nothing misbehaves with this
afaict.
Differential Revision: https://phabricator.services.mozilla.com/D199609
Make it less error-prone by adding a HasProperty(AnimatedPropertyId&)
overload.
Also make the range checks a diagnostic assert rather than a non-fatal
NS_ASSERTION.
Differential Revision: https://phabricator.services.mozilla.com/D197045
This patch also updates the bug ID for a FIXME leftover from bug 1840478
to bug 1869476, since the same FIXME is added in D190758.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D191322
Differential Revision: https://phabricator.services.mozilla.com/D190758
This will make possible to animate custom properties on Gecko side. For now, the
animation code keeps only dealing with nsCSSPropertyID, so behavior is unchanged.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D190816
Differential Revision: https://phabricator.services.mozilla.com/D191059
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
Instead of starting transitions and animations as a result of a paint,
use the refresh driver tick to do this.
This sets the transition-ready time to the current time during the next
refresh driver tick that it was started on (see mSawTickWhilePending).
This is similar to what's described in the bugs comments, and seems to
work nicely in practice.
We could easily change that (current time) by a paint-based time if
needed (when available), which would be more similar to what we were
doing. But I'd rather do the simple thing for now, and land this shortly
after the soft freeze is over so that we have time to watch out for
regressions.
There's one regression on a test that birtles wrote (using an XHR doc
and switching the timeline to a rendered doc's timeline).
We use the timeline's document rather than the target document to
determine whether to trigger animations now. That's one of the cases
where we'd keep vsync perma-running without this patch, and Chrome also
fails that test. Maybe the test should be removed / the spec should be
tweaked to allow this behavior?
This causes some progression in some CSS transitions tests too, and I
added an extra test for the vsync behavior.
Over-all this is much simpler to reason about and I think we should try
to do this.
Differential Revision: https://phabricator.services.mozilla.com/D193583
In layout, we build a default `path("m 0 0")` for now. We will implement
it later.
Besides, we don't support compositor animations for `url()`, so we don't
have to serialize it for IPC.
Note:
`<url>` includes `url()` and `src()`. For now we only support `url()`.
We should revisit `src()` in Bug 1845390.
Differential Revision: https://phabricator.services.mozilla.com/D184429
As a bonus we now can throttle some additive and visibility animations
more properly, because before we couldn't compute a change hint for
those but now we don't need to.
Differential Revision: https://phabricator.services.mozilla.com/D185175
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
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 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
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
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
Basically, we need to detect a case if there is only scroll animations
which are not sampled because it goes back to before phase. If this
happens, we set ScrollToDelay to |mReason| in the returned value.
Without this patch, the visual result is intermittent because it
is possible that there are new animations arrived at the moment when
scrolling from active phase to before phase.
We don't have a test for after phase because we don't support end delay
for scroll animations now. However, although we set the adjusted fill, we may
still need this in the future so let's keep the check of after phase for now.
Differential Revision: https://phabricator.services.mozilla.com/D155108
`sTiming` is a hack and I believe animation-delay,
animation-iteration-count, animation-direction, and animation-fill-mode
should be meaningful for scroll-linked animations. (I will add the
tentative wpt in Bug 1775327.)
So we need to introduce a normalized timing when resolving the specified
timing.
Also, this patch makes the bug of printing scroll animations detectable.
No behavior is changed and I'd like to remove the magic values and do
normalization in Bug 1775327.
Note: Based on https://github.com/w3c/csswg-drafts/issues/4862 and
web-animations-2, we will introudce CSSNumberish for duration, current
time, and delay. That is, we will accept percentage for
animation-duration, animation-delay. However, Gecko doesn't support
CSSNumberish for those values, so we'd like to normalize these time values
in Bug 1775327. This patch is the 1st step: split the normalized
timing from the specified timing, and use it when resolving the
timing, for progress-based timeline.
Differential Revision: https://phabricator.services.mozilla.com/D149683
None of the consumer need to mutate styles, and this saves some ugly
const_casting on the next patch.
Doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D147555
We fallback to use main-thread animations if the timeline is inactive or we
cannot get scroll offsets or the scroll range from APZC on the compositor
thread.
Differential Revision: https://phabricator.services.mozilla.com/D141168
We don't send the animation to the compositor if it's scroll-timeline is
inactive (e.g. no layout frame or no scrollable frame).
Besdies, we also add a new struct, ScrollTimelineOptions, to represent
scroll timeline information in the IPC messages.
This patch handles the main thread side, and extract the information
from the transaction and store into AnimationStorageData.
We will sample ths scroll animations later in the patch series.
Differential Revision: https://phabricator.services.mozilla.com/D140548
For simplicity purposes, we don't consider OMTA for now. OMTA support
for scoll-timeline will be done in Bug 1737180.
However, in this patch, we would like to address:
if the geometic animations use scroll-timeline, we don't have to let it
affect the transform animations on the same animation target:
1. If we don't do scrolling, its geometric properties don't change, so no
effect on transform-like properties.
2. If we do scrolling, we may un-throttle the transform animations by
other ways, e.g. Keyframe::CanThrottle(). So we don't need to worry
about this.
Note: tests are in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D129103
This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
