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
Basically, in SetTimelineNoUpdate(), we shouldn't call PostUpdate(). So we
shouldn't call SetCurrentTime() directly.
There is no behavior change. Just make sure we don't PostUpdate twice
while updating an existing CSS animation via changing animation-timeline.
Differential Revision: https://phabricator.services.mozilla.com/D161245
It's possible to change the timeline if the animation is in pending. So
we still need an animation tracker to track the scroll-linked
animations. Besides, per the spec, we should keep this animation in
pending if its timeline is inactive. So in this patch, we always put the
scroll-linked animations into ScrollTimelineAnimationTracker, and if we
change the timeline but the animation is still in pending, we move the
animation into the correct animation tracker if needed.
Using two different animation trackers because we would like to trigger
scroll-linked animations after frame construction and reflow,
and don't want to ensure the paint is scheduled.
Note:
1. All tests in scroll-timeline-dynamic.tentative.html are failed. We
will fix them in Bug 1774275.
2. Drop `animation-duration: infinite` from
progress-based-animation-animation-longhand-properties.tentative.html,
because infinite is not defined in animation-duration in [css-animations-1].
Differential Revision: https://phabricator.services.mozilla.com/D159650
It's possible to change the timeline if the animation is in pending. So
we still need an animation tracker to track the scroll-linked
animations. Besides, per the spec, we should keep this animation in
pending if its timeline is inactive. So in this patch, we always put the
scroll-linked animations into ScrollTimelineAnimationTracker, and if we
change the timeline but the animation is still in pending, we move the
animation into the correct animation tracker if needed.
Using two different animation trackers because we would like to trigger
scroll-linked animations after frame construction and reflow,
and don't want to ensure the paint is scheduled.
Note:
1. All tests in scroll-timeline-dynamic.tentative.html are failed. We
will fix them in Bug 1774275.
2. Drop `animation-duration: infinite` from
progress-based-animation-animation-longhand-properties.tentative.html,
because infinite is not defined in animation-duration in [css-animations-1].
Differential Revision: https://phabricator.services.mozilla.com/D159650
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
It's always true, so remove it.
Add another pref to allow -webkit-line-clamp to work on all blocks
rather than just legacy -webkit-boxes, which seems something we should
try to look into, eventually.
Depends on D155181
Differential Revision: https://phabricator.services.mozilla.com/D155182
This patch doesn't impact behavior.
The pref "gfx.font_loader.interval" used to control certain aspects of
font-loading behavior, but that code has evolved and we no longer read the
value of this pref anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D155183
If both end time and start delay are Infinity, the result of interval
end time is undefined, so now we return zero duration to avoid the
assertion in StickyTimeDuration.
Differential Revision: https://phabricator.services.mozilla.com/D153818
We store active duration as int64_t, multiplying a finite duration by a finite
iteration count would result over INT64_MAX, it will be represented as a
negative integer value. Both animation duration and interation count should
never be negative, thus multiplying them also should be positive so that
treating such kind of overflowed values as infinite would be more reasonable
than treating it as negative.
Differential Revision: https://phabricator.services.mozilla.com/D152721
Emilio Cobos Álvarez
Boris Chiou
Adam Vandolder
Andrew McCreight
Nazım Can Altınova
Iulian Moraru
Tom Ritter
Botond Ballo
Butkovits Atila
Cosmin Sabou
Sandor Molnar
Hiroyuki Ikezoe
Noemi Erli
Olli Pettay
Mark Banner
Daniel Holbert