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
* 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
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
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
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
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
We call NS_FRAME_SET_TRUNCATION (via nsReflowStatus::UpdateTruncated) in the end
of every frame's Reflow() to update nsReflowStatus::mTruncated bit. In the
following patches, I'm going to rewrite all the callers of IsTruncated(), and
ultimately remove the mTruncated bit.
In this patch, I rewrite the callsite in ReflowCellFrame() by moving
nsReflowStatus::UpdateTruncated logic [1] into it. Note that we use an assertion
in ReflowCellFrame to make sure nsTableRowFrame and nsTableCellFrame have the
same writing-mode.
The only test covering the code path is `layout/reftests/bugs/409084-1a.html`.
[1] https://searchfox.org/mozilla-central/rev/2946e9b450cb35afaf8dad927a8d187975dcd74d/layout/generic/nsIFrame.cpp#256-258
Differential Revision: https://phabricator.services.mozilla.com/D151459
This patch doesn't change behavior.
I was initially going to promote this param to be const (which is an
improvement that's unlocked by earlier patches this series), but in doing so
I realized the param is entirely unnecessary. So, let's just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D149678
`nsIFrame::IsRelativelyPositioned()` tests "position:relative" or
"position:sticky", but its naming is misleading until you've dug into the
underlying helper `nsStyleDisplay::IsRelativelyPositionedStyle()`.
Differential Revision: https://phabricator.services.mozilla.com/D140273
