This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
Values were static_casted where required. Some functions in WritingModes.h were
rewritten such that bitwise operations aren't being used. Added static_casts to
avoid (debug) build errors from debugging printfs in layout/tables/nsCellMap.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D205510
Bug 1861562 Part 6 [1] made a bold assumption that TableBCDataProperty should
only be set on first-in-flow, but apparently a table continuation can call
`GetOrCreateTableBCData()` to set the property in the testcase [2].
This patch restores the old behavior that allows TableBCDataProperty to be set
on table continuations.
[1] https://hg.mozilla.org/mozilla-central/rev/c9c310c769d2
[2] Note: we don't support fragmenting tables in multicol. Table continuations
are created in this testcase because the abspos `<dialog>` in the table
is fragmented.
Differential Revision: https://phabricator.services.mozilla.com/D203707
Bug 1861562 Part 6 [1] made a bold assumption that TableBCDataProperty should
only be set on first-in-flow, but apparently a table continuation can call
`GetOrCreateTableBCData()` to set the property in the testcase [2].
This patch restores the old behavior that allows TableBCDataProperty to be set
on table continuations.
[1] https://hg.mozilla.org/mozilla-central/rev/c9c310c769d2
[2] Note: we don't support fragmenting tables in multicol. Table continuations
are created in this testcase because the abspos `<dialog>` in the table
is fragmented.
Differential Revision: https://phabricator.services.mozilla.com/D203707
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
