"random" is used where the bug is likely in the test, or the test was already
random on other platforms because the feature was not complete.
"fails" is used where it looks like the bug is in the product, so that we know
to re-enable the test with the product is fixed.
MozReview-Commit-ID: FenLhua7tm8
--HG--
extra : rebase_source : f93e5a67036174fcc20ef9209c731b311190f362
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
--HG--
extra : rebase_source : 5715c1f9ec43da3c8374f08cdca82e2ca29fe474
The check of negative elapsedDuration is basically no longer valid since
animation delay is not factored into start time any more. But still we have
somtimes met negative elapsedDuration sice we use a previous vsync time stamp
for async animations to make the animations more sync. This is not a problem
in most cases but makes two reftests intermitent failure because both of them
used steps(1, start), the steps(1, start) composed different results in the
before phase and in the active phase. To avoid this difference this patch
replace the steps(1, start) with steps(1, end).
Once we incorpolate playbackRate into GetCurrentOrPendingStartTime, we don't
need to call AnimationTimeToTimeStamp for deviding delay by playbackRate since
the time passed to AnimationTimeToTimeStamp does not contain delay any more.
MozReview-Commit-ID: IVE2IFfNgm0
--HG--
extra : rebase_source : 7cb42e57067c21451706bd89284016d996dc8b12
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
These tests aim to confirm that part 5 does not cause any regressons.
MozReview-Commit-ID: BtZ1OGiilmQ
--HG--
rename : layout/reftests/css-animations/no-stacking-context-animation-ref.html => layout/reftests/css-transitions/no-stacking-context-transition-ref.html
rename : layout/reftests/css-animations/stacking-context-animation-ref.html => layout/reftests/css-transitions/stacking-context-transition-ref.html
The spec says that single-line flex containers should stretch their one flex
line to the flex container's cross size, and should ignore 'align-content'.
Initially, the spec defined 'single-line' to include any flex container that
happens to have only 1 line (even if it's got 'flex-wrap:wrap' or
'wrap-reverse'). But later, the term 'single-line' was intentionally redefined
to *only* include flex containers that have 'flex-wrap: nowrap'. So, instead
of checking the line-count, we should instead check 'flex-wrap', when deciding
whether to stretch our one line & ignore 'align-content'.
MozReview-Commit-ID: D2ZMIBS16ui
--HG--
extra : rebase_source : 835a64e0f9cdaa375f8e57f55ffe5b011525cbeb
The spec says that single-line flex containers should stretch their one flex
line to the flex container's cross size, and should ignore 'align-content'.
Initially, the spec defined 'single-line' to include any flex container that
happens to have only 1 line (even if it's got 'flex-wrap:wrap' or
'wrap-reverse'). But later, the term 'single-line' was intentionally redefined
to *only* include flex containers that have 'flex-wrap: nowrap'. So, instead
of checking the line-count, we should instead check 'flex-wrap', when deciding
whether to stretch our one line & ignore 'align-content'.
MozReview-Commit-ID: D2ZMIBS16ui
--HG--
extra : rebase_source : c600a80b96df3c937f2a56a5e0ed1825750234e0
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
--HG--
rename : layout/reftests/css-animations/no-stacking-context-animation-ref.html => layout/reftests/css-transitions/no-stacking-context-transition-ref.html
rename : layout/reftests/css-animations/stacking-context-animation-ref.html => layout/reftests/css-transitions/stacking-context-transition-ref.html