The background image is associate to the table frame, but the table wrapper frame is the primary frame, thus IsPrimaryFrameOfRootOrBodyElement returns false and we don't propagate to the root when we should. So I changed IsPrimaryFrameOfRootOrBodyElement to handle this case and renamed it. I checked the other root element frame types, only table frames had this issue.
Differential Revision: https://phabricator.services.mozilla.com/D217923
Ruby layout requires the first box inside an nsRubyFrame to be an
nsRubyBaseContainerFrame, even when empty, so we can't eagerly remove
it.
Differential Revision: https://phabricator.services.mozilla.com/D214173
- Remove "FRAME" for nsBlockFrame state bits for the consistency with other bits.
- Use helpers instead of checking state bits if possible.
- Tweak one line documentation to use C++ comment style.
- Move `GetMarker()` to protected section because it is used only internally.
Differential Revision: https://phabricator.services.mozilla.com/D213698
So that removing stuff under an anonymous box (such like emptying a table that
has an anonymous table cell) doesn't have to re-create the table itself, which
could trigger pathological behavior if that needs to remove more stuff (due to
it being inside an ib-split for example).
To do that, unify how we deal with anonymous wrapper boxes a little bit, which
avoids the need to special-case the grid/flex anonymous items too, and
optimizes them in the same way. E.g., emptying a div like:
<div style="display: flex">Some random text</div>
Will no longer reframe the <div>, just remove the text and the anonymous
wrapper.
We need to remove the eTypeBlock check added in bug 500467 since now removing a
table-related pseudo might in fact need white-space to be suppressed or
un-suppressed. This is tested by some of the table-anonymous-boxes reftests.
Differential Revision: https://phabricator.services.mozilla.com/D212292
So that removing stuff under an anonymous box (such like emptying a table that
has an anonymous table cell) doesn't have to re-create the table itself, which
could trigger pathological behavior if that needs to remove more stuff (due to
it being inside an ib-split for example).
To do that, unify how we deal with anonymous wrapper boxes a little bit, which
avoids the need to special-case the grid/flex anonymous items too, and
optimizes them in the same way. E.g., emptying a div like:
<div style="display: flex">Some random text</div>
Will no longer reframe the <div>, just remove the text and the anonymous
wrapper.
We need to remove the eTypeBlock check added in bug 500467 since now removing a
table-related pseudo might in fact need white-space to be suppressed or
un-suppressed. This is tested by some of the table-anonymous-boxes reftests.
Differential Revision: https://phabricator.services.mozilla.com/D212292
We've tried to give `nsFileControlFrame` its own frame type "FileControl", but
it caused a crash and we revert its frame type back to "Block" in Bug 1825623.
That prevents the crash, but the frame tree is not correct since
`nsFileControlFrame` will have `nsBlockFrame` as its next-in-flow.
The proper way to fix the crash is disallowing the form control frame to split,
similar to what we did for `nsTextControlFrame` in
https://searchfox.org/mozilla-central/rev/fc76676f61ee37b4c5420649cad6677164a29405/layout/forms/nsTextControlFrame.cpp#670
This patch doesn't mean to promote frame type usage, but it might help the
broader frame type audit in the future once we switch frame type to QueryFrame
in bug 1555477.
Note this patch might have potential behavior changes since calling
`IsBlockFrame()` on `nsFileControlFrame` now returns `false` instead of `true`.
However, we have other concrete frames such as `nsMathMLmathBlockFrame`,
`nsSelectsAreaFrame`, etc. which have frame type "Block", and callers who need
to check `nsBlockFrame` and its subclasses are probably already using
`IsBlockFrameOrSubclass()`.
Differential Revision: https://phabricator.services.mozilla.com/D212188
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
Timothy Nikkel