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
Before, there existed 3 virtual functions that calculated baselines:
- `GetLogicalBaseline`
- `GetVerticalAlignBaseline`
- `GetNaturalBaselineBOffset`
Each of them had slightly different behaviours:
- `GetLogicalBaseline` would synthesize a baseline if there is no baseline.
Others would simply return `false`.
- `GetNaturalBaselineBOffset` requires the caller to pick which of first/last
baseline to calculate. Others pick on on their own.
- `GetNaturalBaselineBOffset`'s result can be either offset from border box
start/end edge, depending on the caller-supplied baseline. Others always
return offset from border box start edge.
Now:
- `GetNaturalBaselineBOffset` is the sole virtual function.
- `GetLogicalBaseline` exists to support its use, with 2 virtual helper functions:
- `SynthesizeFallbackBaseline` to generate a baseline for elements that
doesn't have one.
- `GetBaselineSharingGroup` to preserve the default baseline picking behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D167990
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
This patch is based on Mats Palmgren's idea bug 1599159 comment 0.
When a child block frame reports inline-break-before status after being
reflowed, its size in the returned reflow output shouldn't matter because the
parent is expected to push it to the next page/column [1].
Here is the detail of the debug assertion if the workaround in fieldset frame is
removed. In nsBlockReflowContext::ReflowBlock(), it sets mReflowOutput::BSize()
to 0xdeadbeef, which is a negative number in 32-bits integer. Without the early
break of the loop in nsBlockFrame::ReflowBlockFrame(), then later in the loop we
are going to pass the negative block-size to
BlockReflowState::GetFloatAvailableSpaceForBSize(), which triggers a `aBSize>=0`
assertion further down in the callstack in nsFloatManager::GetFlowArea().
layout/reftests/pagination/fieldset-00G.html can trigger the above assertion
after removing the workaround in fieldset frame.
I don't expect this patch will change the behavior even if there are some float
elements interacting with this block. Without the early breaking out of the
loop, we still end up in [1].
[1] https://searchfox.org/mozilla-central/rev/ace2c59e6c56b2dcba25af1aa8903a5e7f9a5857/layout/generic/nsBlockFrame.cpp#4026-4035
Differential Revision: https://phabricator.services.mozilla.com/D148815
This removes the last use of DefineClip from Gecko, which will
allow removing and simplifying a lot of the clip handing code
during scene building in WR.
Differential Revision: https://phabricator.services.mozilla.com/D118121
The helper is going to be used in a later part.
I don't add the physical version ComputedPhysicalBorder() deliberately
because I don't want to promote the usage of physical coordinate.
Differential Revision: https://phabricator.services.mozilla.com/D114544
This patch is generated via the rename functionality in my editor; add
`mozilla::` prefix to `OverflowAreas` in headers; and remove the
`OverflowType` alias added in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D97235
Similar to the optional aContainingBlockSize parameter, both border and
padding should use logical coordinates in ReflowInput::mFrame's writing
mode.
Table frames that need to override border and padding can be simplified a bit.
However, DR_init_constraints_cookie and DR_init_offsets_cookie become more
complex, but they're only for debugging. I'm not planning to update their
internal APIs.
Differential Revision: https://phabricator.services.mozilla.com/D95369
Both are aliases to IntrinsicISizeType::MinISize and
IntrinsicISizeType::PrefISize.
Remove MOZ_ASSERT in nsLayoutUtils::IntrinsicForAxis and
nsContainerFrame::DoInlineIntrinsicISize since IntrinsicISizeType is a
enum class nowadays, which cannot have other values.
I've compiled this patch with DEBUG_INTRINSIC_WIDTH defined in
nsLayoutUtils.cpp, and fixed aWM undefined in
nsLayoutUtils::MinSizeContributionForAxis().
Differential Revision: https://phabricator.services.mozilla.com/D94618
nsContainerFrame.h was only using the enum nsLayoutUtils::IntrinsicISizeType,
which this patch moves to LayoutConstants.h instead.
Depends on D91505
Differential Revision: https://phabricator.services.mozilla.com/D91506
