Closed Bug 1874823 Opened 1 year ago Closed 10 months ago

Merge NS_BLOCK_STATIC_BFC and NS_BLOCK_DYNAMIC_BFC into a single bit

Categories

(Core :: Layout, task)

task

Tracking

()

RESOLVED FIXED
125 Branch
Tracking Status
firefox125 --- fixed

People

(Reporter: fredw, Assigned: emilio)

Details

Attachments

(3 files)

In bug 1765615, two flags were introduced to describe block formatting context:

  • NS_BLOCK_STATIC_BFC for frames that are always BFC after construction/initialization.
  • NS_BLOCK_DYNAMIC_BFC for frames to set the BFC property dynamically after a restyle (currently due to CSS paint/layout containment change)

We can probably merge them into a single flag.

Comment from Emilio on D198530:

So I guess the idea behind having both of these (instead of just one) is basically that we don't know otherwise whether a frame is meant to always be a BFC (because of NS_NewBlockFormattingContext or so) vs. due to a style change, right?
That seems fixable nowadays, tho... A lot of the anonymous blocks that we create like ::-moz-fieldset-content, etc could use display: flow-root rather than display: block for example.

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.

This patch instead makes StyleEstablishesBFC() return true for
IsColumnContainerStyle() 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.

The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:

  • nsComboboxControlFrame
  • nsFileControlFrame
  • nsSelectsAreaFrame
  • ColumnSetWrapperFrame
  • nsMathMLmathBlockFrame

Do that in nsBlockFrame::Init instead, by attempting to cast to these
classes. Behavior is unchanged.

With the two attached patches, the remaining AddStateBits(NS_BLOCK_STATIC_BFC) are:

  • NS_NewBlockFormattingContext
  • nsBlockFrame::Init
  • nsBlockFrame::SetMarkerFrameForListItem
  • nsFieldSetFrame::SetInitialChildList/InsertFrames
  • nsCSSFrameConstructor::ConstructNonScrollableBlock
Assignee: nobody → fwang
Attachment #9375418 - Attachment description: WIP: Bug 1874823 - Use NS_BLOCK_DYNAMIC_BFC flag on multi-column containers. r=#layout → Bug 1874823 - Use NS_BLOCK_DYNAMIC_BFC flag on multi-column containers. r=#layout
Status: NEW → ASSIGNED
Attachment #9375432 - Attachment description: WIP: Bug 1874823 - Make nsBlockFrame::Init set NS_BLOCK_STATIC_BFC by checking classes. r=#layout → Bug 1874823 - Make nsBlockFrame::Init set NS_BLOCK_STATIC_BFC by checking classes. r=#layout
Keywords: leave-open
Pushed by fwang@igalia.com: https://hg.mozilla.org/integration/autoland/rev/a38e1f388fd2 Use NS_BLOCK_DYNAMIC_BFC flag on multi-column containers. r=layout-reviewers,emilio https://hg.mozilla.org/integration/autoland/rev/f5d297181393 Make nsBlockFrame::Init set NS_BLOCK_STATIC_BFC by checking classes. r=layout-reviewers,AlaskanEmily

(In reply to Sandor Molnar[:smolnar] from comment #5)

Backed out for causing assertion failures at builds/worker/checkouts/gecko/layout/generic/nsBlockFrame.cpp

Backout link: https://hg.mozilla.org/integration/autoland/rev/db6542a5ca6182386e394ed6199d33e0b0480e36

Push with failures

Failure log -> Assertion failure: false (MOZ_ASSERT_UNREACHABLE: aFrame should be a block), at /builds/worker/checkouts/gecko/layout/generic/nsBlockFrame.cpp:7768

Mmh, indeed this new code is reachable, it's expected that there are other frame types that should render false. Will reland with that fixed.

Flags: needinfo?(fwang)
Pushed by fwang@igalia.com: https://hg.mozilla.org/integration/autoland/rev/2c0d41730484 Use NS_BLOCK_DYNAMIC_BFC flag on multi-column containers. r=layout-reviewers,emilio https://hg.mozilla.org/integration/autoland/rev/4e0e2448d7a5 Make nsBlockFrame::Init set NS_BLOCK_STATIC_BFC by checking classes. r=layout-reviewers,AlaskanEmily
Pushed by fwang@igalia.com: https://hg.mozilla.org/integration/autoland/rev/301bb1f39c5e Use NS_BLOCK_DYNAMIC_BFC flag on multi-column containers. r=layout-reviewers,emilio https://hg.mozilla.org/integration/autoland/rev/c6fb12843569 Make nsBlockFrame::Init set NS_BLOCK_STATIC_BFC by checking classes. r=layout-reviewers,AlaskanEmily
Flags: needinfo?(fwang)

(In reply to Frédéric Wang (:fredw) from comment #3)

With the two attached patches, the remaining AddStateBits(NS_BLOCK_STATIC_BFC) are:

  • NS_NewBlockFormattingContext
  • nsBlockFrame::Init
  • nsBlockFrame::SetMarkerFrameForListItem
  • nsFieldSetFrame::SetInitialChildList/InsertFrames
  • nsCSSFrameConstructor::ConstructNonScrollableBlock

The remaining cases seem a bit more involved. I'm unassigning myself in case someone wants to take over.

Assignee: fwang → nobody
Status: ASSIGNED → NEW

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.

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/18a81dc9dbb2 Remove NS_BLOCK_STATIC_BFC and NS_BLOCK_CLIP_PAGINATED_OVERFLOW. r=fredw
Keywords: leave-open
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: