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
--HG--
extra : rebase_source : 96dfef60ed87b94fe7ec1ea5c3104658e283b3ea
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
--HG--
extra : rebase_source : 7bba8907fa7e57695a8294cf9277804fbe23ff8f
This goes with a crashtest, as soon as I get a usable build.
MozReview-Commit-ID: LqmPWoJZ7AJ
--HG--
extra : rebase_source : a2f2e4b0b2f3cfa4c0f53bc5110d31f0fb86667f
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
--HG--
extra : rebase_source : 7e8371199bde8148d77cb69417a8dd8b1ee77078
(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
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
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
--HG--
extra : rebase_source : 72641ee76a953357a00cb58b993a4316a86be618
extra : amend_source : 97b7053710039859dfe18c073c6414b129030757
Skips flushing current document if the target of getComputedDOMStyle cannot be
affected by any pending restyles.
MozReview-Commit-ID: C87HDIDvOth
--HG--
extra : rebase_source : 064880493f9aac2599689cdd0749200bb579c60b
This was added in bug 1384769 for passing into Servo_TakeChangeHint,
but bug 1388031 changed Servo_TakeChangeHint to no longer take it, and
there is nothing else in the function which uses the flags.
MozReview-Commit-ID: LvZkJZHENUB
--HG--
extra : rebase_source : 609ad8d6be0946898622671b4f8092745e9da36a
In particular, this avoids the stupid calls in display: none roots.
The cache stuff should be unnecessary, but there's still some fishy stuff going
on.
MozReview-Commit-ID: LgnW0k1gmsN
--HG--
extra : rebase_source : b07e1f2533e4a2fc1610f35351fc2964f37e82e2
Bindgen bitfield enums don't work as return values with the Linux 32-bit ABI at
the moment because they wrap the value in a struct.
This causes the Rust side to believe the caller will pass along space for the
struct return value, while C++ believes it's just an integer value.
MozReview-Commit-ID: 6qqVVfU8Mb2
--HG--
extra : rebase_source : 825985977307b50ae8a80ab182e54a3f7b95eafc
This patch changes UpdateAnimationOnlyStyles to only flush animation styles if
there are throttled animation styles that could affect hit-testing and renames
the function to UpdateAnimationStylesForHitTesting at the same time.
For GeckoRestyleManager, the original UpdateAnimationOnlyStyles which flushes
animation styles if there are any pending animation styles, is renamed to
UpdateAnimationStyles for consistency.
MozReview-Commit-ID: 89UleXjI2OE
--HG--
extra : rebase_source : cac59f9d48b096aee718f89ffe203d38d39027fd
I'm still not quite sure how may we end up restyling a text node under there,
but all my attempts to build a test-case have failed.
Anyway this is the right thing to do.
MozReview-Commit-ID: FitqSKhNt2n
--HG--
extra : rebase_source : 23daa450b11d3bbee458973fc62e95338328fe02
Now that we do process normal traversal even in the case of throttled animation
flush so that we don't need to do special handling for the case.
Note about the comment in has_current_styles():
the remaining animation hints is not caused by either this patch or the
previous patch in this patch series, it's been there in the first place, but
it should be fixed somehow later. See bug 1389675.
MozReview-Commit-ID: JojHufxNCiS