The old style system can't find the appropriate style to inherit from when
::first-line and display: contents are involved...
MozReview-Commit-ID: 98t1ABgLulQ
It doesn't make sense, since they have no frame themselves, and it breaks
invariants other code relies on. Use the parent frame instead.
The stack overflow happens because we give the first-letter frame to the
display: contents element, then we reframe it.
Removing a display: contents node calls ContentRemoved on all the children. One
of these children is this text-node inside the first-letter frame. Since it was
split by bidi resolution we go ahead and reframe the parent in:
https://searchfox.org/mozilla-central/rev/d2b4b40901c15614fad2fa34718eea428774306e/layout/base/nsCSSFrameConstructor.cpp#9688
But the parent is the display: contents node, which results in infinite
recursion.
The usage of GetParent() is wrong anyway too, since it doesn't handle XBL or
Shadow DOM in any way.
MozReview-Commit-ID: JFD16at316V
--HG--
extra : rebase_source : e485b45bc146a70c26f8534f760899218da07500
Deletion at the end of a text-node ends up translated to an empty append. It's
harmless though.
Reviewers: xidorn
Bug #: 1442506
Differential Revision: https://phabricator.services.mozilla.com/D667
MozReview-Commit-ID: DqheOYVWx8o
The crashtest will crash whenever the shell is destroyed, which is annoying,
but...
MozReview-Commit-ID: 1JkLy5K98bS
--HG--
extra : rebase_source : 063ca56df3db72940dbb3537a36da561528a5949
Bug 1427292 broke display: contents on non-special MathML elements.
Just for reference, I've manually audited calls to nsIFrame::GetContent() in
MathML and turns out that MathML is pretty well-behaved in that sense (it
inspects the frame tree, then gets the content), so it should work fine with
display: contents / ShadowDOM.
Only exception to that is[1], but that one seems harmless.
[1]: https://searchfox.org/mozilla-central/rev/eeb7190f9ad6f1a846cd6df09986325b3f2c3117/layout/mathml/nsMathMLmactionFrame.cpp#301
So we can enable or implement when the CSSWG pleases.
MozReview-Commit-ID: 8N6kiGyjE4i
--HG--
extra : rebase_source : a80197e39b20bc6ab385a3d0b90628bc4ad81d92
Most of the Shadow DOM related code are behind "dom.webcomponents.enabled" and
this pref is only used by Shadow DOM right now, so we should rename it to
"dom.webcomponents.shadowdom.enabled"
MozReview-Commit-ID: er1c7AsSSW
The only reason not to do that is when there's after content in there. We know
that there isn't really any ::after content, since it would've been handled by
FindNextSibling, so we know we're performing a real append.
MozReview-Commit-ID: ExoPolZy4gG
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
It turns out, this is the only case in which we need to do the fixup at all.
And this way we don't have to guess based on first-line styles, which may not
match the frame tree (for example if we have a pending style change that we
haven't processed yet).
nscoord_MAX is (1<<30) so that we can check for overflow *after* adding
two nscoords. However, (nscoord_MAX + nscoord_MAX) will still overflow.
Subtracting one makes this no longer possible.
MozReview-Commit-ID: BtbQRMp5kWm
Emilio Cobos Álvarez
Sebastian Hengst
Jessica Jong
Kartikaya Gupta
Mats Palmgren
Edgar Chen
Botond Ballo
Boris Zbarsky
Makoto Kato
Jesse Ruderman
Xidorn Quan
Manish Goregaokar
J. Ryan Stinnett