In this case we have a shadow hoot with display: contents, with no children.
Those children wouldn't be flattened tree children of the shadow host.
Instead of using the last light dom child and seek to it, use
FlattenedChildIterator's reverse iteration.
MozReview-Commit-ID: 18XL5Ong7ww
Second test-case is because I initially made this code work with
display: contents. But then realised that display: contents meant allowing
Shadow DOM in there, which I don't really want to deal with right now.
MozReview-Commit-ID: HSjFbWEbPAb
Move the assertion to the earliest point where it can happen instead, and do it
automatically on exit if it's generated content instead of relying on manual
calls.
MozReview-Commit-ID: 5oPwXg2o22V
This also adopts the resolution of [1] while at it, and switches XUL to not
support display: contents until a use case appears.
This makes our behavior consistent both with the spec and also in terms of
handling dynamic changes to stuff that would otherwise get suppressed.
Also makes us consistent with both Blink and WebKit in terms of computed style.
We were the only ones respecting "behaves as display: none" without actually
computing to display: none. Will file a spec issue to get that changed.
It also makes us match Blink and WebKit in terms of respecting display: contents
before other suppressions, see the reftest which I didn't write as a WPT
(because there's no spec supporting neither that or the opposite of what we do),
where a <g> element respects display: contents even though if it had any other
kind of display value we'd suppress the frame for it and all the descendants
since it's an SVG element in a non-SVG subtree.
Also, this removes the page-break bit from the display: contents loop, which I
think is harmless.
As long as the tests under style are based in namespace id / node name /
traversal parent, this should not make style sharing go wrong in any way, since
that's the first style sharing check we do at [2].
The general idea under this change is making all nodes with computed style of
display: contents actually honor it. Otherwise there's no way of making the
setup sound except re-introducing something similar to all the state tracking
removed in bug 1303605.
[1]: https://github.com/w3c/csswg-drafts/issues/2167
[2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700
MozReview-Commit-ID: JoCKnGYEleD
Much in the spirit of bug 1442207.
They're not only unneeded, and cheap to get, but also we call them
inconsistently with the light DOM and flattened tree parent (like ContentRemoved
for display: contents), so they're really confusing, and kind of a footgun.
MozReview-Commit-ID: 9u3Kp8Kpp5i
The code was trying to assert that we had frames constructed for all the nodes
in the parent chain, but we don't bail out in the
!GetContentInsertionFrameFor(aContainer) in the case that it's a children
element, because they actually have no insertion frame, though their children
do.
Move the LazyFC check after the insertion point check. That makes the previous
check work on the insertion point of the child, which makes it sound.
This also fixes bug 1410020, and with it a Shadow DOM test-case that was failing
because we had two sibling assigned to two different <slot>s, and the second one
wasn't getting properly flagged, and thus the second sibling never got a frame.
The other two test failures in this test are an event dispatch failure, where
the position of the target is not what the test expects (we don't account for
margin and padding). Filed that as bug 1450027.
Also, added a test for which we have wrong layout without these patches, and
that crashes with "Called Servo_Element_IsDisplayNone" with the first patch of
this bug applied but not this one, due to the bogus check mentioned above.
MozReview-Commit-ID: 6OeaVrZhTDv
This is mostly code removal, changing GetDisplayContentsStyle(..) checks by an
FFI call to Servo.
The tricky parts are:
* MaybeCreateLazily, which I fixed to avoid setting bits under display: none
stuff. This was a pre-existing problem, which was wallpapered by the
sc->IsInDisplayNoneSubtree() check, which effectively made the whole
assertion useless (see bug 1381017 for the only crashtest that hit this
though).
* ContentRemoved, where we can no longer know for sure whether the element is
actually display: contents if we're removing it as a response to a style
change. See the comment there. That kinda sucks, but that case is relatively
weird, and it's better than adding tons of complexity to handle that.
* GetParentComputedStyle, which also has a comment there. Also, this function
has only one caller now, so we should maybe try to remove it.
The different assertions after DestroyFramesForAndRestyle are changed for a
single assertion in the function itself, and the node bit used as an
optimization to avoid hashtable lookups is taken back.
MozReview-Commit-ID: AZm822QnhF9
Tag is unused.
This changes how some mixes of MathML and html get wrapped in anonymous table
boxes (in particular, it changes whether it uses a MathML or an HTML table
frame). The main thing this affects is whether the frame responds to certain
attributes. Responding to mathml attributes on its mContent when that mContent
is not a MathML element is weird. So arguably this is also more correct.
However, that seems acceptable to me, and you can already get that mixing
manually. On a few (arguably simple) manual test-cases mixing MathML and HTML
tables I couldn't manage to get the patched build to render differently.
Plus, neither our reftests nor the WPT MathML test-suite upstreamed by Fred Wang
for WebKit rely on this.
MozReview-Commit-ID: 8IV3iF5xIs0
The old style system used FlattenedTreeIterator for lazy frame construction.
That could not find native anonymous nodes, so we had to construct eagerly in
native anonymous subtrees. Servo uses StyleChildrenIterator for the same
purpose, and that knows about native anonymous content, so we can now do lazy
construction for it.
Also, not check the container to do lazyFC on the children, it's no longer
necessary to check for anon content, and the reason we check for XUL is because
of XBL bindings, and those are loaded for the parent already, if we're about to
construct frames for the children.
Also, assert more tightly, we don't insert NAC lazily, that makes no sense.
Well, to be fair editor does insert anonymous nodes lazily sometimes (see al the
ManualNAC machinery), but it goes through the PostRecreateFramesFor path, not
through ContentInserted / LazyFC.
MozReview-Commit-ID: 2TmRNgpWaM
We don't need the parent style context, nor the pseudo-element dance or anything
like that. All end up in the same place, Servo_ResolveStyle.
We cannot assert for text style resolution because of non-lazy frame
construction, and we cannot remove non-lazy frame construction because of XBL.
This is effectively the same code, since the old code passed the parent style
around from the frame tree / display contents map, which didn't have a similar
assertion either... Slow steps.
I'll improve and cleanup LazyFC in bug 1447506.
MozReview-Commit-ID: Ck4RCoFLGOi
The whole function doesn't have much sense.
I killed its only DOM use in bug 1427511.
Now it only has two callers in nsCSSFrameConstructor, which basically only want
to know whether the children of the same node can have different flattened tree
parents.
So let's check that directly instead (checking whether the element has a binding
or a shadow root), and simplify a bit other surrounding code while at it.
Leave the XUL popup / menubar code doing the broken thing they were doing
beforehand, because it doesn't look to me like it's trivial to fix... They're
effectively assuming that the children of the menupopup end up in a single
insertion point, which is true, but doesn't need to be. Maybe they should walk
the DOM tree? Don't want to dig into that right now, since XUL insertion points
can be filtered and all that... Not fun.
Also, this removes the broken optimization that used to check
mParentFrame->GetContent()->HasChildren(), because it's pretty broken. It used
to be relevant before bug 653881, because <children> element used to not exist,
but now the insertion point at least needs to contain the <children> element all
the time.
There even used to be a XXX comment saying that the optimization didn't work,
which was removed in:
https://hg.mozilla.org/mozilla-central/rev/2d8585ec74b3
We could still check for "no insertion points", and optimize that, but it
doesn't seem worth it.
MozReview-Commit-ID: L4lspkxKENr
The whole function doesn't have much sense.
I killed its only DOM use in bug 1427511.
Now it only has two callers in nsCSSFrameConstructor, which basically only want
to know whether the children of the same node can have different flattened tree
parents.
So let's check that directly instead (checking whether the element has a binding
or a shadow root), and simplify a bit other surrounding code while at it.
Leave the XUL popup / menubar code doing the broken thing they were doing
beforehand, because it doesn't look to me like it's trivial to fix... They're
effectively assuming that the children of the menupopup end up in a single
insertion point, which is true, but doesn't need to be.
Maybe they should walk the DOM tree? Don't want to dig into that right now,
since XUL insertion points can be reordered and all that... Not fun.
MozReview-Commit-ID: L4lspkxKENr
We remove async from the DOM all the time now since bug 1389743.
We could, before this patch, recurse into frame construction in a sync way, due
to the way we handle the weird insertion cases for <fieldset>, <details>, and
<mathml>.
This patch makes those also async, making the IssueSingleInsertNotifications
condition unnecessary.
MozReview-Commit-ID: LujPaYPwA4G
InsertFirstLineFrames has been dead for a long time, and I don't think it's
worth to keep it around. It's in the VCS history anyway.
MozReview-Commit-ID: FetYB6nf38D
This is a significant rework of how do we compute the insertion point of a
node.
We handle pseudos in the same function instead of out of band, and also recurse
up when the parent has display: contents, which simplifies the code IMO.
MozReview-Commit-ID: 1rSfv1Tq5gO
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
It's a sub-class of nsAtom, useful for cases where you know you are dealing
exclusively with static atoms. The nice thing about it is that you can use
raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release
implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.)
MozReview-Commit-ID: 4Q6QHX5h44V
(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
It's only used to know whether we may potentially need to sync-style the
subtree.
Given with these patches we guarantee that when inserting sync, we have the
style tree up-to-date, we can just check aInsertionKind for the same effect.
MozReview-Commit-ID: ADvcjkGq5hi
The main purpose of this change is avoiding doing frame construction when the
style tree is not up-to-date.
In the test-case above, for example, a MathML element is changed, and we
schedule style invalidation for it, but another MathML element is inserted, and
we reconstruct the whole thing, using the out-to-date styles from the MathML
element.
There are other cases where this is more problematic than "we just happened to
use out-of-date styles, and we'll restyle eventually", which is when this
reconstruct happens to hit an element which was recently inserted but happened
to lazily construct.
In that case, we haven't even performed initial styling on the element, so we
just panic and crash.
After this the only sync frame construction case remaining when the style tree
is not setup is CharacterDataChanged, which I'll address in bug 1397091.
MozReview-Commit-ID: FSI2Zb34SaZ
