This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
The aSamePointerStructs argument is unused now.
Also, aIgnoreVariables can be true everywhere now, since variable changes can't
generate change hints, and anonymous boxes and such don't care about whether
they really changed or not.
Only one caller cares about struct equality, and that already compares variables
manually as an optimization on the rust side.
We had this optimization inconsistently in some cases but not others.
MozReview-Commit-ID: F2EISKlxR3K
If a single element is inserted in the document, from the lazy frame
construction path we mark it as the restyle root.
It has no restyle data, and we weren't calling ClearServoData when its parent
was being removed from ClearServoDataFromSubtree, thus leaving the stale restyle
root.
MozReview-Commit-ID: GY812b8tDk0
Much like we do in nsIFrame::UpdateStyleOfOwnedChildFrame.
There's also the fact that ::-moz-math-anonymous shouldn't probably be
content-exposed... Oh well.
MozReview-Commit-ID: 8mthwW7Nivy
For an OOF frame, the parent frame that's associated with our parent
style context is the *placeholder's* parent -- not the OOF frame's
parent.
MozReview-Commit-ID: CUSBkWDqxWz
The change is mostly copied from GeckoRestyleManager::AttributeChanged.
It is not clear to me whether it's worth moving it to the superclass so
that we don't duplicate the code. If we are removing the Gecko code in
short term, it probably doesn't matter.
It is also not clear whether we should port other code from that method
to ServoRestyleManager.
MozReview-Commit-ID: Fd1nbwgLGa1
When an insertion point (a) is added to the document before another insertion
point (b), and that insertion point matches nodes that used to match (b), the
following happens in RedistributeAllNodes:
* Loop through (a), and clear the existing insertion points on nodes
distributed into it (none, since it was just inserted).
* Go through the node pool and add the matched nodes. That makes the node
(which already had (b) in the insertion point array) have [(b), (a)] as the
insertion points.
* Go through (b), and clear the existing insertion points on the nodes
distributed to it. That used to do IndexOf() + SetLength(), but since (b) was
the first node by then in the insertion point array, we'll leave the
insertion point array empty, while (a) would still think that the node is
distributed to it.
This causes the bloom filter code, which loops through the flattened tree
parents, to not insert any (because the node doesn't know about where it's
inserted).
Also, add a debug phase to verify the flat tree before restyling that would've
caught this more clearly (happy to remove it if you don't think it's worth).
We still can't assert that the insertion point is properly referenced due to the
hacky way mInsertionPoints is cleared in
HTMLContentElement::UpdateFallbackDistribution, but we'll still clear the
insertion points either there, or on the rest of insertion point removal code in
ShadowRoot::DistributeAllNodes.
MozReview-Commit-ID: 9k2gnsAKMEe
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
We don't follow this bit intentionally because we know that even if it's set,
when none of the other two bits are set there are no other restyle / change
hints down the tree.
We rely on the frame constructor to clean the mess up, though, and it doesn't
really do a good work about it.
In particular, the case we're hitting on the test-case is:
<body descendant-need-frames change=reconstruct style="display: table-column-group">
<div descendant-need-frames>
<div descendant-need-frames>
<span needs-frame></span>
</div>
</div>
</body>
When we see we need to reconstruct the body, we call
ClearRestyleStateFromSubtree, but that doesn't do much now, since we don't
follow the descendant-need-frames bits.
Then, when we reconstruct the content, we arrive at[1] when constructing the
first child <div>. The <div> flags have been cleared, but not the children's!
Then a text-node is inserted in a <div>, breaking all sorts of invariants.
This is the easiest fix. Other fixes include clearing the flags on
SetAsUndisplayedContent. But that implies not clearing them in
ShouldCreateItemsForChild, and doing that somewhere more sensible.
I suspect it's not too hard, but that's a slightly more risky change, will do it
if you prefer it.
[1]: http://searchfox.org/mozilla-central/rev/3dbb47302e114219c53e99ebaf50c5cb727358ab/layout/base/nsCSSFrameConstructor.cpp#6092
MozReview-Commit-ID: 7026wkQLQkz
We don't follow this bit intentionally because we know that even if it's set,
when none of the other two bits are set there are no other restyle / change
hints down the tree.
We rely on the frame constructor to clean the mess up, though, and it doesn't
really do a good work about it.
In particular, the case we're hitting on the test-case is:
<body descendant-need-frames change=reconstruct style="display: table-column-group">
<div descendant-need-frames>
<div descendant-need-frames>
<span needs-frame></span>
</div>
</div>
</body>
When we see we need to reconstruct the body, we call
ClearRestyleStateFromSubtree, but that doesn't do much now, since we don't
follow the descendant-need-frames bits.
Then, when we reconstruct the content, we arrive at[1] when constructing the
first child <div>. The <div> flags have been cleared, but not the children's!
Then a text-node is inserted in a <div>, breaking all sorts of invariants.
This is the easiest fix. Other fixes include clearing the flags on
SetAsUndisplayedContent. But that implies not clearing them in
ShouldCreateItemsForChild, and doing that somewhere more sensible.
I suspect it's not too hard, but that's a slightly more risky change, will do it
if you prefer it.
[1]: http://searchfox.org/mozilla-central/rev/3dbb47302e114219c53e99ebaf50c5cb727358ab/layout/base/nsCSSFrameConstructor.cpp#6092
MozReview-Commit-ID: 7026wkQLQkz
Unlike GeckoRestyleManager::UpdateOnlyAnimationStyles which is called from
*both* GeckoRestyleManager::ProcessPendingRestyles and FlushThrottledStyles,
ServoRestyleManager::UpdateOnlyAnimationStyles is only called from
FlushThrottledStyles which is what we use to update transform animations before
doing hit-testing. In this case, there doesn't appear to be any situation where
throttled SMIL animations need to be updated since SMIL animations are only
throttled when they apply to display:none content (bug 1209405 and bug 1322970)
in which case they should not affect hit testing.
MozReview-Commit-ID: 4bt7hCSa7Xr
