If the table-row-group is styled by CSS and it does not have proper table row
children, anonymous table rows and cells are generated and the real content is
rendered in a placeholder. In this case, the parent of out-of-flow child frame
is the table-row-group frame even though the table-row-group frame has only
anonymous table-row child frame. Therefore, it fails to query `nsTableRowFrame`
and access `nsIFrame` methods with `nullptr`.
This patch allows the method users to set an out-of-flow child frame and
makes the method return "not found".
Differential Revision: https://phabricator.services.mozilla.com/D197983
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
* 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
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
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
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
- Remove unnecessary calls to ClearSize() after declaring a fresh ReflowOutput.
- Use ReflowOutput::SetSize() in nsTableFrame::FixupPositionedTableParts().
Differential Revision: https://phabricator.services.mozilla.com/D163763
After this patch, we still need nsFrameList::Enumerator to iterate
nsFrameList::Slice. We might enhance nsFrameList::Iterator to support Slice, but
I'll leave this for another day.
Differential Revision: https://phabricator.services.mozilla.com/D158809
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
See bug 1758757 comment 0 for the rationale.
Note: the old code in nsTableRowGroupFrame::SlideChild() is bogus because it
calls ApplyRelativePositioning() via the nsTableRowGroupFrame's ReflowInput
instance. That is, it applies relative positioning to nsTableRowGroupFrame, but
not to the aKidFrame (nsTableRowFrame).
While I'm here, I expand `SlideChild` in its only caller, and simplify it.
Differential Revision: https://phabricator.services.mozilla.com/D150323
