Move `SetRootFrame()` to nsFrameManager.cpp, because in order to compile
`mRootFrame = aRootFrame` the compiler requires the full definition of
`ViewportFrame` to know that `ViewportFrame` is a subclass of `nsIFrame`
Differential Revision: https://phabricator.services.mozilla.com/D210671
We can just use `mFrameConstructor` to call `GetRootFrame()`. In order to do so
while keeping `PresShell::GetRootFrame()` as a inline method, we need to include
`nsCSSFrameConstructor` header in `PresShell.h`, and remove `PresShell` header
in `nsCSSFrameConstructor.h`. That means we can no longer inline
`RestyleManager()` since it needs to access `PresShell`, but it's OK since
`RestyleManager` is used only in the frame constructor, and is probably not in
the hot path.
Differential Revision: https://phabricator.services.mozilla.com/D210670
This doesn't yet expose it to a11y but that will be done by the a11y
folks, since this blocks some of the a11y interop test-cases.
Modify the tests to not hit the network, and make -moz-alt-content not
exposed to content (we only need it for UA stylesheets).
Differential Revision: https://phabricator.services.mozilla.com/D209690
This patch stops the frame constructor from inserting nsPageBreakFrame as a flex
item, because flex container does not rely on it to do forced page break at all,
and nsPageBreakFrame can produce wrong layout result.
The majority of this patch is to honor forced break values on flex items in
nsFlexContainerFrame::ReflowChildren(). In this patch, we don't handle avoid
break values such as `break-before:avoid` and `break-after:avoid` since they are
not handled in other frame types yet.
WPTs are added in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D207910
See bug 1574544 and co for previous items in this saga. The editor code
can't go soon enough.
Using FlattenedChildIterator with anonymous children (the
IsRootOfNativeAnonymousSubtree() check) is just not supposed to happen,
as NAC are not flat tree children of their parent.
That is, the common case is hitting the
!IsRootOfNativeAnonymousSubtree() case, regardless of shadow dom.
It's only when editor does something awful like reframing NAC directly
that we hit this.
Differential Revision: https://phabricator.services.mozilla.com/D204892
Put all the "is this block a BFC" logic in nsBlockFrame.cpp.
The CLIP_PAGINATED_OVERFLOW flag is also redundant, it can just be "has
non-propagated overflow styles" check in ShouldApplyOverflowClipping(),
and frees another bit.
Shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D203590
This simplifies our combobox code a bit more:
* Reflow() is only needed to compute the label isize.
* Frame construction uses a setup more similar to <input type=file> to
get the right frame tree, removing a bunch of special code.
* Lots of special code removed all over the place.
Differential Revision: https://phabricator.services.mozilla.com/D203010
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
Per https://drafts.csswg.org/css-multicol/#columns:
"A multi-column container therefore is a regular block container that
establishes a new independent formatting context"
IsColumnContainerStyle() and BeginBuildingColumns() are currently
used in three places and always together (namely
ConstructFieldSetFrame, ConstructFrameFromItemInternal and the
generic ConstructBlock).
BeginBuildingColumns() asserts that aColumnContent is an nsBlockFrame
and that aComputedStyle corresponds to multi-column container. It
always adds the NS_BLOCK_STATIC_BFC to aColumnContent. It also
makes aColumnContent a `PseudoStyleType::columnContent` and that's
the only place where it's used.
This patch instead makes StyleEstablishesBFC() return true for
PseudoStyleType::columnContent so that the NS_BLOCK_DYNAMIC_BFC bit
is set at init and after further style updates. It thus removes the
need for to explicitly set NS_BLOCK_STATIC_BFC in
BeginBuildingColumns().
There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D199091
Per https://drafts.csswg.org/css-multicol/#columns:
"A multi-column container therefore is a regular block container that
establishes a new independent formatting context"
IsColumnContainerStyle() and BeginBuildingColumns() are currently
used in three places and always together (namely
ConstructFieldSetFrame, ConstructFrameFromItemInternal and the
generic ConstructBlock).
BeginBuildingColumns() asserts that aColumnContent is an nsBlockFrame
and that aComputedStyle corresponds to multi-column container. It
always adds the NS_BLOCK_STATIC_BFC to aColumnContent. It also
makes aColumnContent a `PseudoStyleType::columnContent` and that's
the only place where it's used.
This patch instead makes StyleEstablishesBFC() return true for
PseudoStyleType::columnContent so that the NS_BLOCK_DYNAMIC_BFC bit
is set at init and after further style updates. It thus removes the
need for to explicitly set NS_BLOCK_STATIC_BFC in
BeginBuildingColumns().
There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D199091
Per https://drafts.csswg.org/css-multicol/#columns:
"A multi-column container therefore is a regular block container that
establishes a new independent formatting context"
IsColumnContainerStyle() and BeginBuildingColumns() are currently
used in three places and always together (namely
ConstructFieldSetFrame, ConstructFrameFromItemInternal and the
generic ConstructBlock).
BeginBuildingColumns() asserts that aColumnContent is an nsBlockFrame
and that aComputedStyle corresponds to multi-column container. It
always adds the NS_BLOCK_STATIC_BFC to aColumnContent. It also
makes aColumnContent a `PseudoStyleType::columnContent` and that's
the only place where it's used.
This patch instead makes StyleEstablishesBFC() return true for
PseudoStyleType::columnContent so that the NS_BLOCK_DYNAMIC_BFC bit
is set at init and after further style updates. It thus removes the
need for to explicitly set NS_BLOCK_STATIC_BFC in
BeginBuildingColumns().
There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D199091
It was added in bug 1804772. After Part 1, accessing FirstInFlow() is constant
time, so we don't need to duplicate PageValuesProperty in each frame
continuation.
Differential Revision: https://phabricator.services.mozilla.com/D197759
It was added in bug 1804772. After Part 1, accessing FirstInFlow() is constant
time, so we don't need to duplicate PageValuesProperty in each frame
continuation.
Differential Revision: https://phabricator.services.mozilla.com/D197759
After D198523, NS_BLOCK_FLOAT_MGR and NS_BLOCK_MARGIN_ROOT are always
set simultaneously when initiating a frame, so we can merge them into a
single NS_BLOCK_STATIC_BFC flag. The freed bit is used to define a new
NS_BLOCK_DYNAMIC_BFC flag that has the same effect and is now used for
frames with paint/layout containment so that in D197043 they can be
updated later without having to reconstruct the frame tree. Finally
NS_BLOCK_BFC_STATE_BITS is the bitwise union of these BFC flags.
The following changes are made and cause no behavior changes:
- Instead of testing whether NS_BLOCK_FLOAT_MGR or NS_BLOCK_MARGIN_ROOT
is set, or whether all of the bits from
NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS are set, we test whether any
of the NS_BLOCK_BFC_STATE_BITS is set.
- Instead of adding NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS when
constructing a frame, we add NS_BLOCK_STATIC_BFC. The exception is
for frame with paint/layout containment, for which we set
NS_BLOCK_DYNAMIC_BFC instead.
Differential Revision: https://phabricator.services.mozilla.com/D198530
nsCSSFrameConstructor::ConstructSelectFrame is the only place where
these functions are called and the flags parameter is always set to
NS_BLOCK_FLOAT_MGR.
Differential Revision: https://phabricator.services.mozilla.com/D198520
SetNextContinuation() and SetPrevContinuation() are almost always called
together when setting up a continuation link, but the callers don't call them in
particular order. We should unify them as one method so that it's more
ergonomics and robust, especially when we do more complex work such as caching
continuations. Same reason for SetNextInFlow() and SetPrevInFlow().
We choose to merge the SetPrevContinuation() code into SetNextContinuation() for
the symmetry of SetNextSibling(). (Yes, we don't have SetPrevSibling().)
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D197966
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
The top layer fixed list CB and the regular fixed list CB are always the
same (the viewport frame). We're currently using two different
AbsoluteFrameList for these, but that's wrong. Make sure to use the same
AbsoluteFrameList. This makes sure that placeholders for the fixed list
are properly ordered.
Revert bug 1799036 (for now at least), since this also fixes that issue
in a better, less breaking way.
While at it, also insert the top layer abspos list after the
non-top-layer one. This is needed so that a non-top-layer abspos element
and a top layer abspos element are laid out in the right order.
We don't need to share a list for those tho, because all top-layer
abspos items are also abspos containers themselves, so a non-top-layer
descendant of a top layer item can't escape the top layer chain. This
fixes a couple non-fatal asserts.
Differential Revision: https://phabricator.services.mozilla.com/D192908
This is probably something we want to move towards, so it doesn't hurt
adding a pref to allow people to experiment with it.
Differential Revision: https://phabricator.services.mozilla.com/D189919
