The spec doesn't address this, AFAICT, but this makes our rendering better
match Chrome and Safari, and fixes the "disappearing" borders that have been
reported a number of times.
Differential Revision: https://phabricator.services.mozilla.com/D195044
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
If a repeated header/footer row group gets fragmented, so that it has a
next-in-flow, its REPEATABLE flag will be cleared. But in such a case,
nsCellMap still needs to find the "original" in order to get the map
for the repeated frame.
Depends on D193660
Differential Revision: https://phabricator.services.mozilla.com/D193661
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
We really don't need to call `GetNextRow()` repeatedly from `aStartRow` until
reaching `aRow`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D192048
Also, remove `using TableRowGroupReflowInput` statement since it helps my editor
jump directly to `TableRowGroupReflowInput`'s definition rather than to the
alias.
Differential Revision: https://phabricator.services.mozilla.com/D191153
`tableFrame` is seldom used, and all the functions that need the table frame
have already got it via `GetTableFrame()` helper.
Differential Revision: https://phabricator.services.mozilla.com/D191152
We don't need set `haveRow` to `true` in every iteration in the loop over table
rows. It is sufficient to check `GetFirstRow()`.
Differential Revision: https://phabricator.services.mozilla.com/D191151
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
* It used to return useless `nsresult`. Change it to return the block-size
instead of modifying the argument to return value.
* Shorten its name to `CalcCellActualBSize` to match `CalcBSize`.
Differential Revision: https://phabricator.services.mozilla.com/D190377
While I'm here, revise GetFirstRow(), GetLastRow(), and GetNextRow(), and add
assertions to them to ensure the correctness of table frame tree structure.
Differential Revision: https://phabricator.services.mozilla.com/D190376
nsTableRowFrame's children are all nsTableCellFrame, and `GetFirstCell()` has an
assertion for that. Hence, we can delete the unreachable code dealing with
non-cell frames.
Differential Revision: https://phabricator.services.mozilla.com/D190375
We don't ever remove `NS_TABLE_ROW_HAS_UNPAGINATED_BSIZE` bit, so let's set the
bit directly in `SetUnpaginatedBSize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D190374
It is confusing for ResetBSize() to take a parameter to set the fixed
block-size. The caller can call `SetFixedBSize()` if needed.
Differential Revision: https://phabricator.services.mozilla.com/D190373
