Not super-proud of this one, but it's the easiest way I could think of.
The changeset looks bigger than what it is, because while at it I've rewrapped a
fair amount of functions around to use proper block indentation.
Alternatives are parameterizing Stylist by <E>, which is not fun, or moving the
concrete element from layout_thread to layout, but that implies layout depending
on script, which isn't fun either.
Other alternative is implementing an empty enum and making anon boxes work on
it. It has the advantage of removing the annoying type parameter, but the
disadvantage of instantiating `cascade` twice, which isn't great, and having to
maintain all the boilerplate of a `TElement` implementation that just does
nothing.
We only need to do this when display changes from none to non-none, so handle it
explicitly when computing the cascade requirement.
This patch also removes a few conditions that are redundant because they're
handled also by the cascade requirement check, like the initial styling.
It's out-of-band data I never liked, and the code has changed enough from when
it was introduced, that now all of the information it stores can be local.
We already remove all change hints down the tree when finding a reframe hint
using ClearServoRestyleFromSubtree in ServoRestyleManager, so this is useless.
MozReview-Commit-ID: 1twx7iPt79x
We only need to handle changes when the display property is changed from 'none'
when we have a restyle hint for SMIL. The only other case where we expect to
see changes to display property during an animation are from using the CSSOM.
However, when the display property is changed from 'none' by the CSSOM, during
the animation-only restyle we can skip all descendants since they will be
traversed in the subsequent normal traversal because at that time we flush
style sheets and traverse all elements in the document. So we don't need to
care about the descendants during animation-only restyle.
This avoids grabbing the document when values that inherit from the body,
whatever that means, aren't under the body.
In that case we'll get a semi-random value, but that's also mishandled by Gecko
anyways (and probably Blink, though haven't tested), and doesn't really make
much sense.
This avoids grabbing the document when values that inherit from the body,
whatever that means, aren't under the body.
In that case we'll get a semi-random value, but that's also mishandled by Gecko
anyways (and probably Blink, though haven't tested), and doesn't really make
much sense.
First, we define computed::CSSPixelLength which contains a CSSFloat, a
pixel value, and then we replace computed::Length with CSSPixelLength.
Therefore, the |ComputedValue| of NoCalcLength, AbsoluteLength,
FontRelativeLength, ViewportPercentageLength, CharacterWidth, and
PhysicalLength is CSSPixelLength.
Besides, we drop NonNegativeAu, and replace computed::NonNegativeLength
with NonNegative<computed::Length>. (i.e. NonNegative<CSSPixelLength>)
All other browsers get it right because they basically throw away all the styles
in a subtree after a display change. We do better, but need to do this check.
MozReview-Commit-ID: BODx0gnSzwI
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
In the case where values in CSS rules changed directly by CSSOM, the old
value in the CSS rule block is immediately replaced by the new one. So if
the element, which is applied to the CSS rule, has running animations, the
new value is used during cascading process in animation-only restyle. Thus
in a subsequent normal restyle, we can't tell whether the value in the CSS
rule has changed or not. As a result, transitions may not be triggered
(bug 1393323) and CSS animations may not be cancelled if the updated
animation-name is 'none' (this bug).
For the latter case of CSS animations where animation-name has been updated to
'none', this patch introduces a workaround whereby we trigger an update of
running animations whenever the traversal is triggered by changes to CSS rules
and we have existing CSS animations.
The only reason why we had the `existing_style_for_style_damage` bit is to apply
some optimizations that we don't have anymore.
I still want to reintroduce a few of them, at least for the non-eager
pseudo-element case... But I think I won't need this at all.
This allows us to remove a fair amount of Gecko code too.
Make replace_rules_internal return true only if important rules changed.
<!-- Please describe your changes on the following line: -->
https://bugzilla.mozilla.org/show_bug.cgi?id=1367975
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17951)
<!-- Reviewable:end -->
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.
