The elements under <body> are treat as content append, so their frames
will be construct by nsCSSFrameConstructor::ContentAppended.
This patch fixed only the simple "append" case which is appending to the
last continuation of ::moz-column-content. For other more complex
appending or inserting cases, we might need to reframe (bug 1504053).
Differential Revision: https://phabricator.services.mozilla.com/D16076
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This patch also gives nsCSSFrameConstructor.h its own UniquePtr include (since
we have some UniquePtr usage there, but no include). Presumably it's already
getting the include indirectly (via some other header) right now, but it should
really include it directly if it uses the type directly.
(This leaves one nsAutoPtr usage in nsCSSFrameConstructor, for 'mNode'. We can
probably convert that one without too much trouble, but I'm not doing so yet,
in part because we intentionally leak that variable in one spot and I haven't
fully worked out the ownership transfer for that case.)
Differential Revision: https://phabricator.services.mozilla.com/D12992
Other frames calling InitAndWrapInColumnSetFrameIfNeeded() needs to be
modified to support column-span (bug 1489295).
Depends on D5208
Differential Revision: https://phabricator.services.mozilla.com/D5209
Specifically:
- nsICSSAnonBoxPseudo --> nsCSSAnonBoxPseudoStaticAtom
- nsICSSPseudoElement --> nsCSSPseudoElementStaticAtom
The `nsI` prefix isn't necessary because these are no longer XPIDL types, and
the `StaticAtom` suffix makes their meaning clearer.
nsCSSFrameConstructor::FindDisplayData() guarantees a block with "display:
list-item" will be constructed by ConstructBlock() (either through
ConstructScrollableBlock() or ConstructNonScrollableBlock()).
This is also a preparation to fix bug 1491915 since we want to control
bullet frame creation under column hierarchy.
Depends on D6840
Differential Revision: https://phabricator.services.mozilla.com/D6841
It's write-only.
Looks like this became unused in bug 501847 when we changed how ib splits work
and no longer needed this information.
Differential Revision: https://phabricator.services.mozilla.com/D2521
MozReview-Commit-ID: GDwcheP3bV4
It was needed presumably because XBL could override the tag name and what not.
But I removed that capability for elements other than XUL elements, so we can
just poke at the content directly.
Differential Revision: https://phabricator.services.mozilla.com/D2520
MozReview-Commit-ID: B5Ihu0gaNd8
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
It's not needed anymore, since we tag the pseudo-elements at creation time for
styling.
Differential Revision: https://phabricator.services.mozilla.com/D2330
MozReview-Commit-ID: 7j4DVEHXYIC
Using references helps to see when stuff can and cannot be null.
I removed useless aTag / aNamespaceId arguments which are useless now that XBL
can't override them (bug 1450617), so FindXULData is the only one that keeps
them alive.
Also, I took the liberty of renaming a few fooComputedStyle variables to just
fooStyle, and clarify naming in some pseudo-element-related functions to say
originating element (the spec term) and avoid confusing it with the generated
_moz_generated_content_before / _moz_generated_content_after element.
Note that this is a partial state, more stuff will come in the future.
Differential Revision: https://phabricator.services.mozilla.com/D2326
MozReview-Commit-ID: 39B30doREUH
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
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
