In Bug 1863421, we'll apply ApplySkipSides() for `borderPadding`. This patch
ensures we use the correct skipped border and padding everywhere.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D194789
Before this patch, we get available block-size in `Reflow()` and available
inline-size in `ReflowTable()`. Then we adjust them in TableReflowInput's
constructor. This patch moves all the computation into TableReflowInput's
constructor.
This is a preparation for bug 1863421, and doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D194788
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
- Better encapsulation.
- Add `AdvanceBCoord()` to adjust block-offset and available block-size at
once.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D193149
This patch might fix table fragmentation when table's writing-mode is vertical.
But I'm in the process of fixing fragmentation, so I don't bother adding
testcase for it.
Differential Revision: https://phabricator.services.mozilla.com/D193145
Putting overflow child frames into the overflow list is a convention in other
layout frame types.
In non-incremental table reflow like printing, a table frame won't have a
continuation until the table wrapper's parent created it. Even if a table does
have a continuation when calling `PushChildren()`, it's totally fine to put
pushed child frames into overflow list since we've called
`MoveOverflowToChildList()` at the beginning of `nsTableFrame::Reflow()` so that
a table continuation can pull them into its principal child list.
Also, rename `PushChildren()` to `PushChildrenToOverflow()` in order to reflect
its purpose and match its counterpart in
`nsContainerFrame::PushChildrenToOverflow()`.
This patch shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D193143
It's more ergonomic to return RowGroupArray directly. While I'm here, improve
its documentation and rename it to `OrderedRowGroups()` since we do not actually
reorder children in table frame's principal child list.
Differential Revision: https://phabricator.services.mozilla.com/D193141
In the previous part, we've fixed `GetIncludedOuterBCBorder()` so that it won't
return empty result while calling from a table's continuation. That means, when
table wrapper frame creates reflow input for a border-collapsed table frame [1],
the computed border and padding is correct for all table continuations. Hence,
when we need border and padding, it is sufficient to get from `ReflowInput`
instead of `GetChildAreaOffset()`.
In `BCPaintBorderIterator` where there is no reflow input, we can call
`GetIncludedOuterBCBorder` directly.
[1] https://searchfox.org/mozilla-central/rev/40d51bef58b8e901d6ab4b60dd280f372a0e417d/layout/tables/nsTableWrapperFrame.cpp#626-633
Differential Revision: https://phabricator.services.mozilla.com/D192054
`TableBCData` is essential for methods like `GetOuterBCBorder`,
`GetIncludedOuterBCBorder`, etc. We need to ensure all the table's continuations
can access it in order to get the border-collapsing border correctly. This patch
changes `GetTableBCData` to reach the first-in-flow for the data (similar to
`GetCellMap()`).
While I'm here, I rename the property, struct, and helpers to make them
consistent, and move the struct to mozilla namespace.
This patch potentially changes behavior when a border-collapsed table is
fragmented, but the layout is very broken (bug 1861575) that I don't feel its
worth writing a test.
Differential Revision: https://phabricator.services.mozilla.com/D192053
This is in order to eventually remove the destruct root.
This is a performance optimization to avoid doing the work of
registration if the table is about to go away anyways. The only thing
this wants to check is whether the first continuation is getting
destroyed. We can do that much more easily, explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D187677
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
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
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
While looking at the backout, I noticed table parts relied on reframing
on abspos-container-ness changes in a subtle way, see the test, which
fails with the first patch of this bug applied without these changes.
Make the NS_FRAME_CAN_HAVE_ABSPOS_CHILDREN mean the same for table parts
as for everything else. Instead, keep the registration status on each
relevant frame class individually.
Depends on D169127
Differential Revision: https://phabricator.services.mozilla.com/D170969
While looking at the backout, I noticed table parts relied on reframing
on abspos-container-ness changes in a subtle way, see the test, which
fails with the first patch of this bug applied without these changes.
Make the NS_FRAME_CAN_HAVE_ABSPOS_CHILDREN mean the same for table parts
as for everything else. Instead, keep the registration status on each
relevant frame class individually.
Depends on D169127
Differential Revision: https://phabricator.services.mozilla.com/D170969
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
This patch doesn't affect behavior; it's dead-code removal.
UpdateForFrameBackground is never called, and hence can be removed.
The member-var that it conditionally set, mPartHasFixedBackground, can be
assumed to be always false, and hence can be removed.
The same struct's other member-var, mDrawsBackground, is irrelevant since it's
only checked in combination with mPartHasFixedBackground, and hence can be
removed. And with that, the local variable invalidateForAttachmentFixed can
be removed as well.
This all seems to be code that's obsoleted by our (long-ago) move to using
display lists to draw tables.
Differential Revision: https://phabricator.services.mozilla.com/D149680
