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
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. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
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
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. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
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
Right now, we reconstruct frames in response to a change in the CSS
`contain` property or `content-visibility`. This patch tries to optimize
this a bit:
1. Updates involving style containment change continue to force a
reconstruction, due to the need to handle counters/quotes.
2. Updates involving paint/layout containment change only force a
reconstruction if it's needed to handle absolutely/fixed
positioned descendants or floats (for this one, see also bug 1874826).
3. Other containment changes will only force a reflow and repaint.
Per the CSS contain spec, layout, style and paint containments are
enabled for `content-visibility: hidden` and `content-visibility: auto`.
As a consequence, changing `content-visibility` between `hidden` and
`auto` values no longer requires reconstruction. Changing between these
values and `visible` may need a reconstruction although authors may
generally avoid that in practice by forcing `style` containment.
Differential Revision: https://phabricator.services.mozilla.com/D197043
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
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
This corresponds to how Chrome behaves, and passes the test they included in WPT.
It's unclear to me whether this behavior actually follows from the current spec
(see https://github.com/w3c/csswg-drafts/issues/9310), but it seems to be the desired
result.
(I've put it behind a (default-enabled) pref for now, so that it's possible to
experiment with the two possible interpretations, but we can remove the pref once
the spec question is clarified/confirmed.)
This patch also disables balancing for fragmented/overflowing blocks, as that will
not currently work well. We may want to address that as a followup issue (though it
won't matter to the primary balance use-cases such as titles).
Depends on D188139
Differential Revision: https://phabricator.services.mozilla.com/D188220
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
This corresponds to how Chrome behaves, and passes the test they included in WPT.
It's unclear to me whether this behavior actually follows from the current spec
(see https://github.com/w3c/csswg-drafts/issues/9310), but it seems to be the desired
result.
(I've put it behind a (default-enabled) pref for now, so that it's possible to
experiment with the two possible interpretations, but we can remove the pref once
the spec question is clarified/confirmed.)
This patch also disables balancing for fragmented/overflowing blocks, as that will
not currently work well. We may want to address that as a followup issue (though it
won't matter to the primary balance use-cases such as titles).
Depends on D188139
Differential Revision: https://phabricator.services.mozilla.com/D188220
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
This corresponds to how Chrome behaves, and passes the test they included in WPT.
It's unclear to me whether this behavior actually follows from the current spec
(see https://github.com/w3c/csswg-drafts/issues/9310), but it seems to be the desired
result.
(I've put it behind a (default-enabled) pref for now, so that it's possible to
experiment with the two possible interpretations, but we can remove the pref once
the spec question is clarified/confirmed.)
This patch also disables balancing for fragmented/overflowing blocks, as that will
not currently work well. We may want to address that as a followup issue (though it
won't matter to the primary balance use-cases such as titles).
Depends on D188139
Differential Revision: https://phabricator.services.mozilla.com/D188220
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
This is the first patch of bug 1684236 tweaked as per review comments.
Keeps us with one source of truth for reflowInput.
This could be cleaned up in the future if we manage to remove that
printing hack or what not.
Co-Authored-By: fantasai <fantasai.cvs@inkedblade.net>
Differential Revision: https://phabricator.services.mozilla.com/D181857
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This patch introduces functional pseudo parameters, i.e. `::highlight(foo)`,
for `getComputedStyle()`. This required adapting the parse algorithm (`nsCSSPseudoElements::ParsePseudoElement()`) and forwarding the functional pseudo parameter into the style engine.
Differential Revision: https://phabricator.services.mozilla.com/D183773
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
When balancing columns, if a block frame doesn't have enough available
block-size for a float's continuation, we move the float continuation into the
block's pushed floats list.
Typically, the float's continuation is expected to be pulled by the block's next
continuation and reflow there. However, if the block happens to be in the *last*
column, the float continuation will stay in the pushed float list until we
reflow its block again in the next column balancing loop. In this case, we
should pull it from the pushed floats list regardless of whether the
continuation has a previous continuation or not. Otherwise, it will not be
reflowed if it remains in the pushed floats list.
Differential Revision: https://phabricator.services.mozilla.com/D178141
This patch shouldn't change the behavior.
- Use `nsIFrame::PresShell()` to get PresShell directly.
- Rewrite the loop, and rename `next` to `prevSibling` for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D178140
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
The only functional change in this patch is the added `else` clause.
Other changes are non-functional such as removing the `Note` and retrieving
block-end BP directly from `borderPadding` (an alias of
`BlockReflowState::BorderPadding()`). We can simplify it because nowadays
`BlockReflowState::BorderPadding()` won't skip the block-end border and padding,
and `mBorderPadding` is initialized with `PreReflowBlockLevelLogicalSkipSides()`
[1], which always assumes the current fragment is the last fragment.
The only difference between the added test and reference file are `height` and
`max-height`, so the test verifies the fragmentation are consistent internally.
[1] https://searchfox.org/mozilla-central/rev/4a5c56f4aca291802ce27320cd9a752dd5dd955e/layout/generic/BlockReflowState.cpp#43-46
Differential Revision: https://phabricator.services.mozilla.com/D176614
