I'm not sure exactly how this works, but test_smilTextZoom.xhtml passes so this
appears to be taken care of.
MozReview-Commit-ID: C04XjX2rtZw
--HG--
extra : rebase_source : 19c08a1267f8764f83e9e7b31731bb82e52df9e6
Currently, Gecko converts lengths in stroke-* properties to numbers when
creating animation values and hence the result of animation is always a unitless
value for these properties.
Servo, on the other hand, converts lengths for these properties to numbers
during interpolation and hence sometimes the result of animation is a unitless
value, and other times (such as when skipping interpolation) it is not.
Other browsers produce lengths with px units and ultimately we should align
with that behavior. As a result, this patch updates various SMIL mochitests to:
* Expect animation values with px unit
* Compare values by stripping px units as a temporary measure until we
correctly serialize these values with px (bug 1379908).
MozReview-Commit-ID: IsT26DKkgiP
--HG--
extra : rebase_source : 8d8dee6ad53d29801096d3affe996e4df1a9388c
We need to check whether the function fails or not in order to check whether
we support the specified paced animation values.
Current servo returns 0.0 when failed computing distance, so servo doesn't
distinguish its failure. This patch makes Servo_AnimationValue_ComputeDistance
return a negative value when the function fails.
MozReview-Commit-ID: 43Q4gu4xwHc
--HG--
extra : rebase_source : fa159b4b03e2e84c0a365455de4c0d2cf5d4f2ce
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
In SMIL if a discrete calcMode is used, the keyTimes attribute may be used to
specify the times at which the various animation values are used, overriding the
regular 50% flip behavior (see nsSMILAnimationFunction::ScaleSimpleProgress).
However, this behavior is only applied when the calcMode is known to be
discrete. If the author specifies calcMode="linear" but
attributeType="stroke-linecap" then SMIL should fall back to discrete calcMode
including applying the special keyTimes behavior.
For the Servo backend, Servo_AnimationValues_Interpolate does not return an
error for discretely animated properties so SMIL does not recognize when we fall
back to discrete calcMode. This patch adds a check before performing
interpolation that tests if the property is a discretely interpolable one and,
if it is, returns an error so that we run SMIL's special discrete calcMode
handling.
MozReview-Commit-ID: FOp8XcNbvdu
--HG--
extra : rebase_source : 57ddb333855de111aa585fe894e99937681e5cd2
When display style is changed from 'none' to other in animation-only restyle
we need to resolve descendant elements' style that were in the display:none
subtree.
Three possible ways to resolve the descendant elements' style;
1) Traversing unstyled elements in animation-only restyle
We can't simply traverse unstyled elements in the animation-only restyle
since when we decided to traverse the unstyled elements we don't know yet
the elements will be initially styled or are in display:none subtree. It
will result that the new elements are styled in animation-only restyle,
it's undesirable.
2) Creating a SequentialTask and resolve the descendants' style with
ServoStyleSet::StyleNewSubtree()
We can't resolve the descendants' styles with ServoStyleSet::StyleNewSubtree()
in SequentialTask since at the moment we are still in servo traversal (i.e.
sInServoTraversal is true). That means AutoSetInServoTraversal fails
in PrepareAndTraverseSubtree().
3) Creating a SequentialTask and set restyle subtree hint and defer descendants'
restyle in a subsequent normal traversal
Note that, when we process throttled animations flush, we don't process
normal traversal so the descendants will not be traversed until normal
restyle happens but it will not be a big problem since it's really rare
that user clicks display animation element just at the right moment when
display property changes from none to other. Also, if it will be really
a problem, we should process *only* transform animations on the compositor,
it's ideally right thing to do. Display property never runs on the
compositor.
This patch takes the third approach.
MozReview-Commit-ID: Krxa3kkdIq4
--HG--
extra : rebase_source : 33e9db953f21168c76716329568191625bd15896
AddOrAccumulate in nsSMILCSSValueType.cpp sets initializes |valueToAdd| to
either &valueToAddWrapper->mGeckoValue or nullptr. It then asks
FinalizeStyleAnimationValues to fill it in. FinalizeStyleAnimationValues will
return false if it could not fill it in, in which case AddOrAccumulate returns
early. As a result, after the early return we can be assured that |valueToAdd|
is not null. However, valueToAddWrapper may still be null.
Changeset 4d87f2bf4b10369af0dd83a2ef962a23299ee8d9 from bug 1358966 changed this
code such that we pass a member of valueToAddWrapper to StyleAnimationValue::Add
where we used to pass a member of valueToAdd. As a result, we can end up passing
0x20 (since valueToAddWrapper is nullptr) to Add() and then trying to read from
it.
This patch makes us pass, instead, |valueToAdd| since we know that is guaranteed
to be non-null here.
MozReview-Commit-ID: 1YwT1lBHnUe
--HG--
extra : rebase_source : abec6995af68de13eacaccf7eca7b2d121eaedf3
The spec says,
font weight: interpolated via discrete steps (multiples of 100). The
interpolation happens in real number space and is converted to an integer by
rounding to the nearest multiple of 100, with values halfway between
multiples of 100 rounded towards positive infinity.[1]
However, our implementation pre-dates this spec text (bug 528234 landed Nov 2009
whereas the spec was updated in Mar 2012[2]).
This patch rounds the result by simply adding 50 to the result before we floor
it (which is good enough in this case because we don't need to worry about
negative values).
It also slightly simplifies the logic by re-using Clamp from MathAlgorithms.h.
[1] https://drafts.csswg.org/css-transitions/#animtype-font-weight
[2] 00c6286109
MozReview-Commit-ID: BjCg7MG70hW
--HG--
extra : rebase_source : 879ea18d7d1a49ff425d6e467081983a130a65e3
In case of gecko, we use only the StyleAnimationValue.
Whereas in case of servo, we use RawServoAnimationValue and
make it an array to store multiple values for shorthand sub properties.
MozReview-Commit-ID: 4PnWBk9WP2Q
--HG--
extra : rebase_source : a2b5878f14241c2cbf4adeeed3a0fa08ae230fa3
To traverse pseudo elements in animation-only restyle, the pseudo element
itself needs the animation-only dirty bit.
MozReview-Commit-ID: 11RfVqnPXfJ
--HG--
extra : rebase_source : d048c9a053c03bf3fef46fcbfd9cbd5f60204e1d
Our coding style says we should only use one of either 'virtual' or 'override'.
In the next patch I would like to add another override to this header so first
we should tidy up the existing declarations.
MozReview-Commit-ID: AFtMNvNCcNG
--HG--
extra : rebase_source : 60d0e4fc259ff05aa097a4cf2c10b75883b9deed
If we attempt to call animation-related methods on the Servo backend (e.g.
Servo_ComputedValues_ExtractAnimationValue) and pass a property that is not
(yet) animatable by Servo, it will panic so we should avoid passing these
properties.
An alternative, is to make methods like
Servo_ComputedValues_ExtractAnimationValue fallible by having them first check
if the passed-in value is animatable and return null in that case. That too, is
probably worth doing (call sites like KeyframeEffectReadOnly::EnsureBaseStyle
that assume it is fallible could assert that the result is non-null since,
provided that property is animatable, the method should still be fallible) but
refusing to animate these properties from the start is cleaner so we just do
that for now.
MozReview-Commit-ID: ESYcbkTtfXG
--HG--
extra : rebase_source : 60e4469d0883c49b77118f9235f0f4b369f6cd3f
