Current Gecko does not need this (see bug 1367975 comment 10 for the reason),
but this is the right thing to do for our animation styling machinery
especially for updating animations on the compositor.
MozReview-Commit-ID: H6mgTXMHecG
--HG--
extra : rebase_source : ef2e5127a5c56008771a434cc5c342ebeca1b7be
The KeyframeEffectReadOnly::GetProperties compares AnimationValue's mGecko
member which means it sometimes produces the wrong results when using the Servo
backend. Now that AnimationValue has a suitable operator!= method we can simply
compare the AnimationValues directly.
MozReview-Commit-ID: DQQbmcdeynw
--HG--
extra : rebase_source : 509230cf460308b0a534fe9831e9e0d7fa3b8bee
This test fails without the first patch in this series.
MozReview-Commit-ID: A22aFPnklqj
--HG--
extra : rebase_source : c3a4e1f1dea0444895a3b60c45814c219ff65ac6
Without this mValue may end up looking like a valid nsCSSValue object and bad
things will happen when we try to clone it.
We could just assign mem::zeroed() to mValue but this array hacking on the Servo
side is already pretty nasty and mSimulateComputeValuesFailure would still
remain unassigned (and if we did try to assign it on the Servo side we'd need to
only assign it in debug builds). Unless this proves performance-critical, it's
probably best to just do this on the Gecko side.
MozReview-Commit-ID: 75nFsflhZUM
--HG--
extra : rebase_source : 0e5d94a7f6fdb6768983ba440a3ea69d65cbffbf
Before this refactoring, getComputedStyle could have side effects, and left the
style data in the element, so we could never arrive there without data.
There are a few crashtests that caught this, but this was already broken if you
called animate() on an element deep in a display: none subtree.
MozReview-Commit-ID: 1AvOvhAyOP3
--HG--
extra : rebase_source : 0a920df8809961f784026a14a624d8eafb4cc79f
The previous patch takes the approach that we should simply not add elements in
documents without a pres shell to EffectCompositor's set of elements to restyle.
However, there exists a case where we might have an element in a displayed
document, then we might tickle it so that it requests an animation restyle, and
then move it to a document without a browsing context. In that case we should
skip the element when we next do animation restyles.
However, even if we successfully skip the element in the document without a pres
shell, we need to make sure it eventually gets removed from the set of elements
to restyle rather than simply remaining there forever. For that reason this
patch makes us unconditionally clear the set of elements to restyle whenever we
do a full restyle from the root.
This patch also adds a test case to trigger the scenario outlined in the first
paragraph above. I have confirmed that without the code changes in this patch,
if we simply assert that target.mElement has an associated pres shell in
getNeededRestyleTarget, then that assertion will fail when running this test
case.
MozReview-Commit-ID: ED2X5g39hYZ
--HG--
extra : rebase_source : 06fecc98c25c739d26123bddf1fd0908cf4410e6
extra : source : 12c7a036215a901bf6804c0e9aacd2a9fc20f932
This patch makes us ignore animation restyle requests for elements in documents
without a pres shell made by either:
* Calls to EffectCompositor::RequestRestyle (e.g. by calling Web Animations API
methods on animations that target such elements)
* Calls to EffectCompostior::PreTraverse(dom::Element*, CSSPseudoElementType)
(e.g. by calling getComputedStyle(elem).prop on such an element).
The other overloads of PreTraverse should presumably be called during regular
document restyling where the element is expected to be in a displayed document
and hence we simply assert that that is the case for those methods.
MozReview-Commit-ID: FZD0hKAXYEf
--HG--
extra : rebase_source : 9b9ddf4648b49e0241054ffa51a02ae66f1c5009
Update the various animation restyle tests to check the new animation only data
inside the restyle marker.
MozReview-Commit-ID: HEe8x45IhHj
--HG--
extra : rebase_source : fdaa5855e94d68ce2a70d00fde11582c9a538f45
Since we implement following properties animatable, append to test.
* -moz-border-bottom-colors
* -moz-border-left-colors
* -moz-border-right-colors
* -moz-border-top-colors
MozReview-Commit-ID: E3zWaDcRdtE
--HG--
extra : rebase_source : 27301a4bc354f14cf3f90e8c8271be6022d99721
For this test case, we can't use global '::before' and '::after' selectors
since it changes visiting order for the pseudo elements on updating styles
and leads to different results of observed records.
MozReview-Commit-ID: 4e4eZTmr0gJ
--HG--
extra : rebase_source : f966aef3145e317a81262eaf67f402a80af3a90c
