For display:table content we generate two frames: a table wrapper frame and an
inner table frame. The styles are applied to the inner frame (referred to as the
style frame), whilst the wrapper frame is the primary frame for the content.
However, in order to make tables with transforms behave as a container for
abspos/fixed-pos content as required by the spec, we apply the transform to the
wrapper frame (bug 722777) by inheriting the transform from inner to wrapper and
then ignoring the transform on the inner frame (bug 722777 and bug 816458).
When handling animations on table elements we need to be careful of this
distinction. in particular, css animations[1] and web animations[2] require that
when we have an unfinished transform animation targetting an element, the
element acts as if it had `will-change: transform` applied and therefore
generates a stacking context. As a result we need to accurately detect when
a frame should be considered as having transform animations applied to it or not
for the purpose of creating a stacking context.
Previously our handling of display:table content was quite inconsistent and
contradictory. For example, `nsIFrame::HasAnimationOfTransform` would check for
a primary frame AND for animations on that frame, despite the fact that we only
ever store animations on the style frame. As a result it could never return true
for either a table wrapper or inner table frame.
This patch attempts to make this handling at least a little more consistent,
producing the following result:
Outer table frame (primary frame):
nsIFrame::IsTransformed → true
nsIFrame::IsCSSTransformed → true
nsIFrame::HasAnimationOfTransform → true
nsLayoutUtils::HasAnimationOfProperty(frame, eCSSProperty_transform) → false
Inner table frame (style frame):
nsIFrame::IsTransformed → false
nsIFrame::IsCSSTransformed → false
nsIFrame::HasAnimationOfTransform → false
nsLayoutUtils::HasAnimationOfProperty(frame, eCSSProperty_transform) → true
We maintain that the NS_FRAME_MAY_BE_TRANSFORMED bit is only set on the primary
frame whilst the mMayHaveTransformAnimation flag is only set on the style frame.
Note that we don't simply always put everything on the primary frame because for
other property types (e.g. opacity) the default setup of putting all styles and
animations on the style frame is simpler and correct. So far it is only
transforms that require special handling to apply the effect to the wrapper
frame.
This patch adds a reftest that fails without the code changes included in this
patch.
[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section
Differential Revision: https://phabricator.services.mozilla.com/D21883
--HG--
extra : moz-landing-system : lando
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified.
Unlike other patches in this series, compositing is not frequently used
internally (e.g. by DevTools etc.) so there is no need to enable this by default
for system code.
Also, it turns out we have inadvertently been shipping part of this feature for
some time now. The next patch in this series will add tests for that case and
disable that part of the feature (a suitable intent to unship will follow). This
patch merely adapts and extends the existing tests without affecting the surface
area covered by the combination of the newly-added pref and the existing
dom.animations-api.core.enabled pref.
MozReview-Commit-ID: Htr6mlyCBav
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_compositing.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_compositing.html
extra : rebase_source : 7715a25e59568eb122ba3f7dbd2c2b2ffdd19954
Many tests set the dom.animations-api.core.enabled pref to true when all they
really require are the features covered by the dom.element-animate.core.enabled
pref. Now that we have removed that pref and permanently enabled that
functionality we can drop the annotations from such tests.
MozReview-Commit-ID: CGOLp6pVFLE
--HG--
extra : rebase_source : e298e9404d76d55421d9ca4b514410d02cc243b1
If reftest-no-flush is not specified, reftest harness flushes layout in a
callback of setTimeout() that happens after paint process happened in the next
refresh driver's tick. Thus, the paint process triggered by the layout flush
causes no invalidation changes, so reftest harness ends up waiting for the
animation end until the animation finishes.
MozReview-Commit-ID: GXvmyXh0kfV
--HG--
extra : rebase_source : 091a91122b7337ff05032bd64fa2597e59bed3a4
Refrests without specifing reftest-no-flush flush all pending styles so that
we don't need to wait for a requestAnimationFrame to apply the final style
changes.
MozReview-Commit-ID: lAFsFG8CrE
--HG--
extra : rebase_source : 46ba219da0ccbb1bee0d8243b7e2ee5f8d81a13f
This test is supposed to append *animating* element to the document.
MozReview-Commit-ID: 39kvw6IYRF9
--HG--
extra : rebase_source : 510e99190fb60067b0bf404c37d7250e2d994ff0
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
This reftest fails without the first patch.
This test generates animation-only restyle by anim.cancel() and selector
matching by classList.add().
MozReview-Commit-ID: 2EvOWRwr1o7
--HG--
extra : rebase_source : bfa2f94a5726142577f75074f28415caf87cd53a
After enabling animations running on compositor, it seems to me that we
can enable reftests in layout/reftests/web-animations without intermittents.
MozReview-Commit-ID: 5Whwm0UZ8nQ
--HG--
extra : rebase_source : a0db68e521ff3143bf8f52d3e31eaff115f35bb2
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
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
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
To create a stacking context for animations on transform:none segment,
we need to set NS_FRAME_MAY_BE_TRANSFORMED. The fix is comming in part 2.
Note that in case of animations which has properties preventing running on
the compositor, e.g., width or height, corresponding layer is not created
at all, but even in such cases, we normally set valid change hint for such
animations in each tick, i.e. restyles in each tick. For example:
div.animate([{ opacity: 1, width: '100px' }, { opacity: 0, width: '200px' }], 1000);
This animation causes restyles in every ticks without this patch, this patch
does not affect such animations at all. The only animations which will be
affected by this patch are animations which has opacity/transform but
did not have those properies. e.g, setting transform by setKeyframes or
changing target element from other target which prevents running on the
compositor, etc.
MozReview-Commit-ID: 78fYqyX8uDX
--HG--
extra : rebase_source : c4a6ef244f26f3d808fd2c6a5f80c1a15478ae31
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
