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
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
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
Currently, attribute and child arrays (implemented in dom/base/nsAttrAndChildArray.h) start out empty. When cloning, the array ends up being resized multiple times in order to add the attributes and children that are being cloned from the original node. This would be quicker if the array was initialized to the correct size in the first place so that resizes are not necessary.
However, preallocating space for children is only necessary when performing a deep clone. Therefore, an additional parameter is being added to the Clone, CopyInnerTo, and CloneDocHelper methods to indicate whether preallocation of children should happen. Attributes are copied either way, so that part of the array is preallocated in both cases.
MozReview-Commit-ID: 3iVezeAKXnI
This assumes that it's safe to possibly shrink the tables after the removal,
i.e. there are no surprising subtleties with how these tables are managed.
