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
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
