So, we don't create a stacking context for this case. Besides, we also
make sure FindAnimationsForCompositor() work properly for motion-path if
offset-path is not effective (i.e. none and no animations).
Differential Revision: https://phabricator.services.mozilla.com/D51895
--HG--
extra : moz-landing-system : lando
As with the previous patch in this series, we need to pay particular attention
to how we handle display:table content when detecting animations on a element.
Please see the extended description in that patch for an explanation of
different frame types involved.
As with transforms, our handling of opacity is also inconsistent. In
particular, we fail to return true from nsIFrame::HasOpacityInternal for
display:table content with opacity animations applied due to the conflicting
requirements for a primary frame and having opacity animations (which are stored
on the style frame).
Unlike transforms, however, we do not inherit the opacity to the table wrapper.
Instead we leave it on the inner table frame. As a result, we should not check
for a primary frame, but instead we should check for the style frame for the
primary frame.
This patch adjusts this handling to check instead for the appropriate style
frame as opposed to requiring a primary frame. It includes a reftest that fails
without the code changes in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D21884
--HG--
extra : moz-landing-system : lando
The animation in this reftests runs on the compositor. In the mean time,
reftest harness waits for the state where there is no pending paint in the
initial phase (STATE_WAITING_TO_FIRE_INVALIDATE_EVENT, i.e. before sending
a MozReftestInvalidate event). So if the animation starts running on the
compositor before a MozReftestInvalidate event is received, it means that
the reftest harness has to wait for the 'no pending paint' state until the
animation finishes because the reftest harness keeps flushing styles in the
initial phase which means the animation causes a paint on every flush.
To avoid above situation, we start the animation in question after we get a
MozReftestInvalidate event.
Differential Revision: https://phabricator.services.mozilla.com/D7681
--HG--
extra : moz-landing-system : lando
As per the CSS Animations spec [1], animations must behave as if 'will-change'
is specified, and as per the Will Change spec [2] the element having
'will-change' property other than 'auto' behaves as a containing block for
fixed-pos descendants. This reftest tests that behavior. The reason we also
specified visibility:hidden there is that we are going to optimize transform
animations on/inside visibility:hidden element, so this reftest also tests it.
In this reftest, if the containing block is correctly generated, the fixed-pos
element is rendered inside the parent element, thus the scrollable element
overflows, then the vertial scroll bar appears.
[1] https://drafts.csswg.org/css-animations-1/#animations
> While an animation is applied but has not finished, or has finished but has
> an animation-fill-mode of forwards or both, the user agent must act as if
> the will-change property ([css-will-change-1]) on the element additionally
> includes all the properties animated by the animation.
[2] https://drafts.csswg.org/css-will-change/#will-change
> If any non-initial value of a property would cause the element to generate
> a containing block for fixed positioned elements, specifying that property
> in will-change must cause the element to generate a containing block for
> fixed positioned elements.
MozReview-Commit-ID: Kx5Fdx8FJUG
--HG--
extra : rebase_source : 926f10590e90a10876339ccbea331a981f9f4773
As per the CSS Animations spec [1], animations must behave as if 'will-change'
is specified, and as per the Will Change spec [2] the element having
'will-change' property other than 'auto' behaves as a containing block for
fixed-pos descendants. This reftest tests that behavior. The reason we also
specified visibility:hidden there is that we are going to optimize transform
animations on/inside visibility:hidden element, so this reftest also tests it.
In this reftest, if the containing block is correctly generated, the fixed-pos
element is rendered inside the parent element, thus the scrollable element
overflows, then the vertial scroll bar appears.
[1] https://drafts.csswg.org/css-animations-1/#animations
> While an animation is applied but has not finished, or has finished but has
> an animation-fill-mode of forwards or both, the user agent must act as if
> the will-change property ([css-will-change-1]) on the element additionally
> includes all the properties animated by the animation.
[2] https://drafts.csswg.org/css-will-change/#will-change
> If any non-initial value of a property would cause the element to generate
> a containing block for fixed positioned elements, specifying that property
> in will-change must cause the element to generate a containing block for
> fixed positioned elements.
MozReview-Commit-ID: Kx5Fdx8FJUG
--HG--
extra : rebase_source : 926f10590e90a10876339ccbea331a981f9f4773
Both tests fail on WebRender without the fix in this patch series.
In the delay phase, those animations should be painted using non-animated
value (i.e. opacity:0 or translateX(100px)), but on WebRender they were painted
using opacity: 1 or identity transform.
MozReview-Commit-ID: DOHopfleWB0
--HG--
extra : rebase_source : 1075557f04d4ae1ce049e2c4513b00287ee9d4be
This reftest passes without reftest-wait, and fails without reftest-wait if the
fix for bug 1395151 is backed-out.
MozReview-Commit-ID: GitJkk014yi
--HG--
extra : rebase_source : 3447145df1c58819ac178f02cb7dbe9cc35c8604
getComputedStyle() ensures triggering new transitions, so we don't need to wait
for a requestAnimationFrame callback.
MozReview-Commit-ID: Bes1vQeHohI
--HG--
extra : rebase_source : fdb8face312a471be5f93229a9fbbfd4fc59418f
Because of bug 1341294, we sometimes receive other MozAfterPaint event that
what we are not waiting for.
MozReview-Commit-ID: 5ltrPv1igs7
--HG--
extra : rebase_source : faf8f760800be4e8dc4bf01fe66381c132910e87
We create empty rectangle (zero-height or zero-width) frame for element which
has no content inside it, e.g. '<p></p>'. And nsRect.Intersects returns false
if either of the rectangles are empty, so if we check
!transformedRect.Intersects(scrollableRect) and transformedRect is empty, we
will end up returning true from IsFrameScrolledOutOfView even though the point
represented by the empty transformedRect might be inside the
scrollableRect.
The reftest causes timeout without this fix since the animation never updates
after the initial paint.
MozReview-Commit-ID: FymFJfjxyGc
--HG--
extra : rebase_source : 6ebcd354be300b779e84f013fa4db7d13e36c551
We had previously started running some tests in layers-free mode
already, either by setting the default-preferences on the folder to
turn on layers-free, or by duplicating an individual reftest annotation
so that it ran in both layers-full and layers-free mode. This patch
removes these changes since layers-free is now the default and we don't
need to run layers-full at all.
MozReview-Commit-ID: JJwB9iO5clU
--HG--
extra : rebase_source : ea20545945b825d7ff829526d4d263850e6b5b7f
This patch:
- adds fails-if annotations for all the reftests that were consistently failing
with layers-free turned on.
- removes fails-if or reduces the range on fuzzy-if annotations for all
the reftests that were producing UNEXPECTED-PASS results with
layers-free turned on.
- adds skip-if, random-if, or fuzzy-if annotations to the reftests that
were intermittently failing due to timeout, obvious incorrectness, or
slight pixel differences, respectively.
MozReview-Commit-ID: A0Aknn6rnjj
--HG--
extra : rebase_source : 420d9cf43f23a5d654fa36eec69138937d13c173
Skip tests that are expected to fail in both Stylo and Gecko modes. They would unexpectedly "pass" in styloVsGecko mode when comparing the two failures, which is not a useful result.
MozReview-Commit-ID: 3mOpjU225Q1
--HG--
extra : rebase_source : 22bb5d4e3c5138ef832995eaf5716824f4707ffe
extra : source : d40fb20c9a49d0797c0eeae613a04912b12a28f7
Skip tests that are expected to fail in both Stylo and Gecko modes. They would unexpectedly "pass" in styloVsGecko mode when comparing the two failures, which is not a useful result.
MozReview-Commit-ID: 3mOpjU225Q1
--HG--
extra : rebase_source : 0c307639c3626af3b6b43e05d3ee73d08b3f47ce
This was a test case for bug 1379203 (Google Inbox issue), but to pass this test
also needs the fix in this series to cancel animations when changing
animation-name to 'none' in the specified CSS rule.
Actually the fix in this series also fixes the Google Inbox issue so that this
test can pass without the fix for the Google Inbox issue. But even so without
the fix for bug 1379203, the style data for the first div element in this test
is cached and the second div element uses the cached data.
MozReview-Commit-ID: GfKSDfTZef4
--HG--
extra : rebase_source : caad72ed69e4ebeec8b8cad25949ea69e3bb652e
In the case where values in CSS rules changed directly by CSSOM, the old
value in the CSS rule block is immediately replaced by the new one. So if
the element, which is applied to the CSS rule, has running animations, the
new value is used during cascading process in animation-only restyle. Thus
in a subsequent normal restyle, we can't tell whether the value in the CSS
rule has changed or not. As a result, transitions may not be triggered
(bug 1393323) and CSS animations may not be cancelled if the updated
animation-name is 'none' (this bug).
For the latter case of CSS animations where animation-name has been updated to
'none', this patch introduces a workaround whereby we trigger an update of
running animations whenever the traversal is triggered by changes to CSS rules
and we have existing CSS animations.
change-animation-name-to-none-in-rule.html fails without servo #18214, succeeds
with this patch. Other two tests succeed regardless of the PR.
MozReview-Commit-ID: BrZgTNk9w41
--HG--
extra : rebase_source : 7a55f54a0f94c8db02639f9d8c89f785b3a17a1b
When a reframe happens on the parent of a pseudo element which has animations,
we need to grab style for the pseudo element that includes the animations'
style and also *replace* old style context (that does not include animations'
style) with it. Otherwise, we will use the old style context that has *no*
animations style, as a result, we will see a flicker right after the reframe.
Two reftests in this patch fail without this fix. One is for CSS transitions,
the other one is for CSS animations.
MozReview-Commit-ID: 6pCdnQ1DGUY
This reftest fails without the first patch on stylo.
MozReview-Commit-ID: E5pBzBw9x8B
--HG--
extra : rebase_source : 4fe2a99bfed76d1b5fb320ef6a4f2b39ee5f5f2c
In case of pseudo elements ElementHasAnimations is set on the parent element.
updating-animation-on-pseudo-element.html fails without this patch, succeeds
with this patch.
MozReview-Commit-ID: HJaX7m8nV96
--HG--
extra : rebase_source : 15466f065d852ebc5fefd5d305639ba366a221f6
reftest-print mode for animations does not work well yet.
We will handle it in bug 1374154.
MozReview-Commit-ID: GUGSEE4VJwQ
--HG--
extra : rebase_source : fd8ee42fd26fc6caaaded7bbaed69188f6005896
This is because in original gecko, canvas background color will merge to
painted layer with other display items. When advanced canvas background
color is enabled, the "other display items" won't be merged with canvas
background color. Which means the layers that are generated by those
display items may not be opaque. So set fails-if to those tests.
MozReview-Commit-ID: 1WbMU8pGtTC
--HG--
extra : rebase_source : c7bc417cde65ece8589d733a63d4a6e1a161d1fe
Hiroyuki Ikezoe
Bogdan Tara
Cosmin Sabou
Boris Chiou
Emilio Cobos Álvarez
Mihai Alexandru Michis
Mats Palmgren
Brian Birtles
Hiroyuki Ikezoe
Margareta Eliza Balazs
Ian Moody
Kartikaya Gupta
Sebastian Hengst
Ethan Lin
Chris Peterson
Phil Ringnalda
Daisuke Akatsuka
Tobias Schneider
Morris Tseng
Shing Lyu