We have to set mHaveNonAnimationRestyles if we have attributes changed
(note: we increase the animation generation only if mHaveNonAnimationRestyles
is set). Attributes changed may create a new transition, and we use the
animation generation as the order of the transition, so
Element::GetAnimations() can return transitions with correct order.
Besides, I think ContentStateChanged() will not trigger a new
transition, so we don't need to make mHaveNonAnimationRestyles there.
MozReview-Commit-ID: J5XgW8nqeLH
This doesn't actually implement style context reparenting in the style set yet; that part is next.
There is one behavior difference being introduced here compared to Gecko: we
don't reparent the first block piece of an {ib} (block-inside-inline) split
whose first inline piece is being reparented. This is actually a correctness
fix. In this testcase:
<style>
#target { color: green; }
#target::first-line { color: red; }
</style>
<div id="target">
<span>
<div>This should be green</div>
</span>
</div>
Gecko makes the text red, while every other browser makes it green.
We're preserving Gecko's behavior for out-of-flows in first-line so far, but
arguably it's wrong per spec and doesn't match other browsers either. We can
look into changing it later.
MozReview-Commit-ID: 5eC6G449Mlh
I was about to assert that other non-primary frames don't have additional style
contexts everywhere, but that wouldn't make much sense, given they don't
correspond to an element we could selector-match against.
MozReview-Commit-ID: EtAQbSg6nP6
This patch also removes the duplication of style contexts during the
restyle, because otherwise pointer equality of ServoComputedValues stops
holding (and we assert on that in a few places)
MozReview-Commit-ID: 7Evc1p8ZfM2
When we process throttled animations restyle for event handling, we skip normal
traversal at all, so after Servo_TraverseSubtree, normally there remains
unstyled elements which have to be processed in normal traversal later. These
elements should be skipped in ProcessPostTraversal too since it's not yet styled!
MozReview-Commit-ID: LgyWQpiFZ8e
ForAnimationOnly is somewhat misleading, it means actually we process
*only* animation-only restyle without normal restyle. The purpose of
ForAnimationOnly is for updating throttled animations to get correct position
of the animations when we need to handle events. Currently we do also update
unthrottled animations though.
MozReview-Commit-ID: HBCCluKrZs9
Adds another restyle generation which represents the dirty state of raw
style changes, so that getComputedStyle() wont be confused by optimizations
made by style engines.
MozReview-Commit-ID: 7RYeNCzFygO
Add restyle markers to `PrepareAndTraverseSubtree` to cover both initial styling
and part of the work of restyling. Also add restyle markers around the post
traversal work in `DoProcessPendingRestyles`.
A new marker is also added around the change hint processing after the post
traversal.
MozReview-Commit-ID: 43PSyCJLikR
Using SVG SMIL it is possible to animate the class attribute of an element using
markup such as the following:
<style>
.red {
fill: red;
}
</style>
<svg>
<circle cx="50" cy="50" r="30" fill="blue">
<set attributeName="class" to="red" begin="1s"/>
</circle>
</svg>
In Gecko, Element::GetClasses handles this case by looking for an animated class
string when the element in question is an SVG element.
This patch causes our Servo bindings to use GetClasses when querying attribute
values for selector matching.
Note that animating the class attribute is *not* expected to affect attribute
selectors such as `circle[class="red"]`. It does in Chrome, but that is due to
a Blink bug where animating attributes using SMIL affects the result of
getAttribute:
https://bugs.chromium.org/p/chromium/issues/detail?id=735820
This patch adjusts the behavior for both the GeckoElement case and the
ServoElementSnapshot case.
MozReview-Commit-ID: DAFWHSH1aYB
In particular, this fixes:
* Restyling of <area> elements that reuse the primary frame mapping for the
image map.
* Restyling of children of display: contents elements when the display:
contents element generates a hint.
* Restyling of out-of-flows (if my analysis in the bug is right).
* Restyling of the ::backdrop pseudo-element.
* Restyling of the Viewport frame.
I only managed to do a reftest for the second one, but the rest of them are
covered by the assertions added.
MozReview-Commit-ID: E7QtiQ1vPqu
This also makes us stop reframing on lack of frame for pseudo-elements for which
such a lack is expected in various situations and means the pseudo-element's
styles do not matter.
MozReview-Commit-ID: K1qzeow2Z6H
::first-letter and ::first-line both want to change the styles of kids, and we
don't want the normal post-traversal for kids to clobber those changes.
MozReview-Commit-ID: 1tIsXz1n0uZ
This also makes us stop reframing on lack of frame for pseudo-elements for which
such a lack is expected in various situations and means the pseudo-element's
styles do not matter.
MozReview-Commit-ID: K1qzeow2Z6H
::first-letter and ::first-line both want to change the styles of kids, and we
don't want the normal post-traversal for kids to clobber those changes.
MozReview-Commit-ID: 1tIsXz1n0uZ
