More improvements to come. In particular, this still iterates through Shadow DOM
in each_xbl_cascade_data, but that should be changed later. That allows to
cleanup a bunch of stuff and finally fix Shadow DOM cascade order.
We still rely on the binding parent to be setup properly in the shadow tree, but
that requirement can go away later (we can walk the containing shadow chain
instead).
This mostly focuses on removing the XBL binding from the Shadow host.
It'd be nice to do EnumerateShadowRoots faster. I think that should also be a
followup, if needed.
MozReview-Commit-ID: Jf2iGvLC5de
Also, change DocumentFragment to use RefPtr, since that's the usual style.
MozReview-Commit-ID: 4PQ19nbmhUh
--HG--
extra : rebase_source : 2afb214b764ba48a4a8718190a6853ae6d6ea80b
Also, make them not rebuild the CascadeData synchronously, via the
FlushSkinSheets call, since that's broken. That fixes bug 1413119.
This is a little step in getting rid of XBL usage for Shadow DOM.
MozReview-Commit-ID: HJ7FeUZlRTW
--HG--
extra : rebase_source : 0fcd0ed461856c1e87e45ef63c9e1d2e81281469
The spec changed in order to align with the error thrown by importNode.
--HG--
rename : dom/tests/mochitest/webcomponents/test_bug1176757.html => dom/tests/mochitest/webcomponents/test_shadowroot_clonenode.html
Now that accessing nsIContent slots is not a blob of virtual function calls, we
should be able to unify logic here, and speed up the not-so-rare case for
chrome, while keeping the usual case fast.
MozReview-Commit-ID: 87iY5Cbhx4T
This also removes some confusing comments around nsIDocument regarding some kind
of "special" stylesheets, which don't seem to exist anymore, and consolidates
StyleSheetList so that we only have one implementation.
I think that fixes a potential leak on the shadow root code (even though the API
is v0 only), given the pointer from the ShadowRootStyleSheetList to the
ShadowRoot wasn't being CCd.
Also, more stuff could be renamed, methods removed, etc, feel free to suggest
more cleanup, I've done mostly the minimal.
Next steps are moving the stylesets there and stop using the proto binding sheet
list / resources.
MozReview-Commit-ID: D9hnDgPQAS5
This also removes some confusing comments around nsIDocument regarding some kind
of "special" stylesheets, which don't seem to exist anymore, and consolidates
StyleSheetList so that we only have one implementation.
I think that fixes a potential leak on the shadow root code (even though the API
is v0 only), given the pointer from the ShadowRootStyleSheetList to the
ShadowRoot wasn't being CCd.
Also, more stuff could be renamed, methods removed, etc, feel free to suggest
more cleanup, I've done mostly the minimal.
Next steps are moving the stylesets there and stop using the proto binding sheet
list / resources.
MozReview-Commit-ID: D9hnDgPQAS5
--HG--
extra : rebase_source : 0597917521894288c6b749e5d3ac6ac3b7db44a0
We should consider slot as a parent in ChildIterator: if slot's
`assignedNodes` is not empty, use `assignedNodes`, otherwise, use direct
children as fallback content.
Also, GetFlattenedTreeParentNodeInternal should be changed to use
`assignedSlot` instead of `DestInsertionPoints`.
Set and unset assignedNodes properly when slot is added/removed and when
slotables are added/removed/modfied. Note that assigedNodes with
flatten: true is calculated on demand.
I'm drive-by removing the comment about the frame tree state because I looked
into it, and the answer is: we properly restore it.
The gotcha is that we retain it too much, indeed, we retain it enough that it
can leak. See bug 1397239.
MozReview-Commit-ID: LP6bXkduEZ4
--HG--
extra : rebase_source : f7e18fc35e48b75c07fcc84b939614d379926828
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
Emilio Cobos Álvarez
Andreea Pavel
Olli Pettay
Dorel Luca
Boris Zbarsky
Jessica Jong
Sebastian Hengst
Cosmin Sabou
Ben Tian