1772383 - Tables don't pull children back from their next-in-flow (but ideally they should)

Status: NEW

(Core :: Layout: Tables, defect)

Description

[Daniel Holbert [:dholbert]]

I'm filing a bug as a placeholder for the issue that's alluded to in the first sentence of this code-comment:

  // tables are not able to pull back children from its next inflow, so even
  // under paginated contexts tables are should not paginate if they are inside
  // column set
  bool isPaginated = presContext->IsPaginated() &&
                     NS_UNCONSTRAINEDSIZE != aReflowInput.availSize.BSize(wm) &&
                     aReflowInput.reflowInput.mFlags.mTableIsSplittable;

https://searchfox.org/mozilla-central/rev/4bce7d85ba4796dd03c5dcc7cfe8eee0e4c07b3b/layout/tables/nsTableFrame.cpp#2777

This turns out to be mostly-fine -- in practice it doesn't cause issues -- since we only allow tables to get fragmented when we print, at which point JS is disabled and we're unlikely to trigger a scenario where we would need to pull content back from a next-in-flow.

However, bug 1767364 did run across one case where we actually do trigger such a scenario where we ideally need to pull back content from a table. See bug 1767364 comment 7 for an overview of what happens.

My paraphrase of what happened to get us into that situation is:

• first we generate a next-in-flow for our table, for a tbody frame that we can't place on the current page.
• then we find out the table frame itself has to be pushed to the next page, too.
• When we reflow the table frame on the next page, ideally it would/should pull any children back from its next-in-flow since it might fit now. But it does not, per this bug here.
• This resulted in the table returning a "complete" reflow-status which prompted us to delete is next-in-flow even though it was nonempty, and this ended up giving us a scenario where a content node unexpectedly had no associated frame.

We're landing a band-aid/workaround for this issue in bug 1767364, but the underlying issue is really the thing described here (tables failing to pull children from their next-in-flow).

I'm not sure how easy this would be to fix / what additional issues might crop up if we did fix it. In particular, if we do fix it, we have take care to avoid pulling thead/tfoot clones from the next-in-flow and ending up with e.g. two thead frames and/or two tfoot frames in a single table frame.

Comment 1

[Daniel Holbert [:dholbert]]

(Looks like bug 888257 is the main bug here; though hypothetically we could fix this bug here without fixing bug 888257.