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
We don't extend svg elements, except in a lone test, that isn't really impacted
by this.
I agree this should look at the frame btw, though that looks a bit out of scope
for this bug.
MozReview-Commit-ID: MbvIE5TszB
The new StaticPrefs machinery means that StylePrefs can be removed.
Note that this approach mirrors all static prefs into Rust, but I have only
updated structs.rs for the prefs that Stylo uses.
On a CLOSED TREE, since a sheriff closed the tree while I was about to land this
via autoland.
MozReview-Commit-ID: G1SY0987WJ7
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
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 nsCSSFrameConstructor bits are now handled in PresShell::Destroy along with
the other refresh driver observers.
I cleaned up the nsRefreshDriver methods because they were using infallible
append anyway, and that simplified the logic.
MozReview-Commit-ID: 1eDUUXjUUS9
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
Unfortunately this means that we need to export a couple more headers, but that
should be ok.
In particular, we have to export some headers that are #included by
nsCSSFrameConstructor.h, because nsCSSFrameConstructor.h itself will now be
included in more places outside of layout/, by .cpp files that don't necessarily
have the ability to indirectly #include its other headers, unless we export
them.
MozReview-Commit-ID: 2n9KHW6Yjrd
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
We never removed the event listeners (the code was there, lol, but the function
that was supposed to call into the tooltip listener returned
NS_ERROR_NOT_IMPLEMENTED instead).
Furthermore, we added an event listener each time we reframed an element, which
is insane. Basically, each time an element with tooltip / tooltiptext gets its
frame tree reconstructed, we add the even listener, again, and we never free it.
Xidorn pointed out that this is not such a huge deal because we deduplicate
event listeners per spec, but still...
Move the code from the RestyleManager and the frame constructor to AfterSetAttr
/ BindToTree / UnbindFromTree in nsXULElement to hopefully make this saner.
MozReview-Commit-ID: 6BQbIQJ87qt
We just need to use the existing StyleChildrenIterator which iterates over them.
We need to be a bit careful though, since ::before and ::after are owned by
their own frame, and thus could be unbound from the tree or even dead after
removing the frame.
Hopefully the only access to the node being removed is unnecessary (anon roots
don't have siblings anyway).
There's also the weird thing of the thing we're iterating changing under the
hood. It works fine for this case, but maybe it would be better to handle them
explicitly like:
if (Element* before = nsLayoutUtils::GetBeforePseudo(aChild)) {
bool didReconstruct = ContentRemoved(aChild, ...);
if (didReconstruct) {
return true;
}
MOZ_ASSERT(!nsLayoutUtils::GetBeforePseudo(aChild));
}
// Same for ::after.
StyleChildrenIterator iter(aChild);
for (..) {
// Do the rest of the kids, which can't get unbound.
}
That'd repeat a bunch of code, so not a fan neither... I pointed this out more
explicitly in a comment instead.
MozReview-Commit-ID: HBsjLH01Db3
This removes the two calls to `FlushPendingLinkUpdates` in nsCSSFrameConstructor
and GeckoRestyleManager, which appear to have no effect.
Looking through what the pending link code is attempting to do:
* When a new anchor is bound in `BindToTree` we do:
1. Link::ResetLinkState(false, Link::ElementHasHref());
* Set link's mLinkState to default (either unvisited or not link)
* Set element's link mState bits to default (either unvisited or not link)
2. doc->RegisterPendingLinkUpdate(this);
* Schedules idle dispatch to run `FlushPendingLinkUpdates` within 1 sec
* In `FlushPendingLinkUpdates`:
* For each pending link, call element->UpdateLinkState(link->LinkState());
1. Register link for async history update to get potential future visited
state
2. mLinkState is still unvisited / not link until we hear from history, so
element state is unchanged
Thus, there seems to be no need to call `FlushPendingLinkUpdates` outside of
`BindToTree`, since visited state is always applied async anyway (so it doesn't
work as an optimization to avoid restyling if visited, since that will trigger
later).
MozReview-Commit-ID: ADwsYz8vNyd
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
