calc() serialization in stylo changed to align to the spec more closely (modulo percentage order).
See the linked issue.
MozReview-Commit-ID: GyzZvdumMSe
In Servo, the max value for 'translate' is different from normal float since
is using Au ( AppUnit ). The value which we introduced as MAX_AU_PX
( 1.78957e+7 ) in this test is calculated by following mechanis.
1. Like this time, if the value is larger than max float, stored into specified
value as infinity by parsing.
2. Then, when converts to the computed value Au from the specified value
(infinity), ABSOLUTE_LENGTH_MAX (1 << 30) = 1073741824 stores into the Au.
[1]
3. Finally, when get the PX value, returns the value which devided by
AU_PER_PX ( 60 ). This value is 1.78957e+7.
[1] to_au_round() method
https://searchfox.org/mozilla-central/source/servo/components/style/values/specified/length.rs#249
MozReview-Commit-ID: BVfDhOKXaWw
--HG--
extra : rebase_source : e55be1f42d9198c35bb8f29882ff19ec9de8f2fa
The serialization of the value in getKeyframes() on both Gecko and Servo is
different, especially 'initial', 'inherit' and 'unset' on discrete animation.
Gecko returns those value as is, but Servo returns computed value.
We are understanding computed value (Servo) is right, so we change expected
values for them. Also, we skip them if this test is running on Gecko.
MozReview-Commit-ID: 4GFpCpec0eP
--HG--
extra : rebase_source : 8bb9fc670fb7ffd56935cdfb4f038be334782de7
Since we made -moz-appearance animatable, append to the moz prefixed properties
test.
MozReview-Commit-ID: 9tdouU1umEB
--HG--
extra : rebase_source : 79e9639360461452249ce54ff538294f25b6cd4f
From the official link for -moz-force-broken-image:
A value of 1 means that the broken image icon is even shown if the image has
an alt attribute. A value of 0 only displays the alt attribute.
It's really ambiguous how we handle other values. Actually stylo's parser
rejects other values. We should use the valid values for this test.
MozReview-Commit-ID: CzmIvsmauke
--HG--
extra : rebase_source : a6387e07b3578cf811bd17f772d791ec73bfa1e7
Unlike Gecko, Stylo currently invokes a needless RequestRestyle(Standard)
for this test case (bug 1388560). For this reason, the check right after
re-attaching the orphaned element passes accidentally.
MozReview-Commit-ID: JUG1dgMUQEX
--HG--
extra : rebase_source : a86d72a41c160edc30f83d82179ebe1226b842de
Actually we have a chance to run styling process when we attach an orphaned
element to a document in this test setup. Precisely, we can process a restyle
between rAF callbacks and Promise.then() callback for waitForAnimationFrames().
So if we call RequestRestyle(Layer) when we attach the element to the document
(bug 1388557), the animation starts restyling in the first frame. *BUT* this
behavior will also change once our micro tasks handling becomes the HTML spec
compliance (bug 1193394). When the micro tasks handling changes, we should also
fix a bunch of test cases and test utilities in bug 1388557.
MozReview-Commit-ID: GyH1ofGhXOP
--HG--
extra : rebase_source : 3536c315960150960fd43286b205c03c584d53ca
DOMWindowUtils.isStyledByServo checks not only the preference value but also
STYLO_FORCE_ENABLED value. This is important especially when we run test on
our CI. On our CI, the preference value is false but just STYLO_FORCE_ENABLED
is set.
MozReview-Commit-ID: FKEd5LFwcxf
--HG--
extra : rebase_source : 1ffd8a68a8339babed14f441bf2d69c9ffd9e3ee
It has been able to pass on stylo since bug 1376248.
MozReview-Commit-ID: 142ptKlqrHe
--HG--
extra : rebase_source : 3bb601122b1593d87a520d3585cc84c0868d6ac8
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
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