This is only used to calculate the block-start border of the overall table,
not and is unused after. Use `Maybe<>` to reflect it as such.
Differential Revision: https://phabricator.services.mozilla.com/D197930
This patch shouldn't change behavior. There was a callsite missed
`SetRepeatable(false)` when the repeated table footer is not allowed, but I
think it was an oversight rather than intentional.
Differential Revision: https://phabricator.services.mozilla.com/D201136
Those callers who using the pointer immediately after getting from
`GetPresShell()` can be replaced with `PresShell()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D199164
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
This does not fix the underlying issue, which is that when the table
got fragmented, we failed to maintain the cellmap (attached to the
first-in-flow) to keep track of the additional rowgroup frame created
to go in the overflowing part of the table.
So this is a wallpaper patch just to prevent the crash here (confirmed
with testcase 5); it'll still throw NS_ASSERTIONs in a debug build,
and in the "bad" case (which depends on details of scaling) some of
the borders will be missing from the print preview/output, but that
seems preferable to crashing.
Differential Revision: https://phabricator.services.mozilla.com/D193660
- 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
Remove `nextRowGroupFrame` variable since `childX + 1` is a valid index of
rowGroups and rowGroups never containing nullptr, `nextRowGroupFrame` is always
valid.
Differential Revision: https://phabricator.services.mozilla.com/D193148
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
We set `aDesiredSize.ISize(wm)` again after calling `ReflowTable()`. Since no
other variable depending on the desired inline-size, there's no point set it
near the beginning of `Reflow()` and in `ReflowTable()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D192052
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
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
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
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
