162 reftests that were previously failing are now passing, and one that was
previously passing is now failing. Sounds like a good tradeoff.
MozReview-Commit-ID: Imw9m2NcD1c
This patch was generated using a script and failure logs from a try push, so
whitespace formatting may not be the same as a human would do. The intent is to
fix many of these failures before merging back to m-c.
MozReview-Commit-ID: Etdx9LlWkLX
mask-*-1a.html: test cases for indirect mask painting.(nsDisplayMask::PaintAsLayer)
mask-*-1b.html: test cases for painting mask on mask layer.(nsDisplayMask::PaintMask)
MozReview-Commit-ID: K9BK4MlnpBE
To send animations to compositor in the delay phase we need to
modify Animation::IsPlaying returning true in the delay phase.
Note about background-position-in-delay.html:
After this patch, background-position animation also creates an active layer
from its delay phase.
Also note about test cases in test_animations_omta.html:
After landing bug 1279071, getOMTAStyle() returns the style value only
specified by animations, also in this patch we don't apply any opacity or
transform values in the delay phase, as a result we can't tell animating
value during delay phase on the compositor.
MozReview-Commit-ID: ILYKig3c08d
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
Note about no-stacking-context-(opacity|transform)-removing-animation-in-delay.html
Before this patch we don't create any stacking context for animations overridden
by !important rules, but after this patch we do create a stacking context for
such animations. As a result, in the test case we did paint a stacking context
in the first rAF callback and then in the second rAF callback we did clear the
painted stacking context. Unfortunately sometimes the second rAF callback was
called prior to clear the stacking context on the compositor because of
compositor delay. To avoid this situation, we have to wait for MozAfterPaint
instead of rAF callback.
MozReview-Commit-ID: AG1Y0IgoB3U
This patch introduces a new functions named HasEffectiveAnimationOfProperty.
This function checks that a given CSS property is overridden by !important
rules.
On the other hand, now KeyframeEffetReadOnly::HasAnimationOfProperty() does
just check that the effect has a given CSS property. This is used to create
a stacking context because we should create a stacking context for opacity or
transform animations even if the property is overridden by !important rules.
MozReview-Commit-ID: AG1Y0IgoB3U
These tests aim to confirm that part 5 does not cause any regressons.
Adding this bunch of reftests makes a slight change in the result of
layout/reftests/bugs/395107-2.html on Android, so fuzzy-if was also
added for the test.
MozReview-Commit-ID: BtZ1OGiilmQ
We should create a stacking context for any transform or opacity animations
that are either "in effect" (what we currently do) OR "current", i.e.
scheduled to run or running. *BUT* for now, we don't create any stacking
context in before phase without fill:backwards or fill:both because the
property never wins in cascade until the animation gets "in effect". This
restriction will be removed in a subsequent patch in this bug after landing
bug 1279403.
MozReview-Commit-ID: 8RyLJNPtoKI
This patch has two test cases one if for CSS animations and one is for web animations.
For CSS animations test cases:
@keyframes {
from, to { transform: none; }
}
For web animtions test cases, the target element is appended after animate().
MozReview-Commit-ID: Gy1sY41jV7G
* partially-out-of-view-animation.html
This test is a normal test case (i.e. a trivial one). An animation on an
element which is partially out of the view. If ofscreen optimization
is totally broken, this test will fail.
* in-visibility-hidden-animation-pseudo-element.html
This test checks animation on visible pseudo element which is attached to
invisible element is not throttled.
* in-visibility-hidden-animation.html
This test checks animation on visible element which is inherited from
invisible parent element is not throttled.
This means that we won't associate animations with additional frames.
In this case, this fixes associating off-main-thread animations with a
table outer frame, when they should have been associated only with the
table frame.
Locally, the test fails without the patch (with opacity in the test
being 0.36 instead of the expected 0.6), and passes with the patch.
(Opacity 0.36 gives a color of rgb(163,163,255), whereas 0.6 gives
rgb(102,102,255).)
