Open Bug 1776769 Opened 2 years ago Updated 2 years ago

Investigate whether it is possible to fix moving nsTableRowFrame in an incremental reflow

Categories

(Core :: Layout: Tables, task)

task

Tracking

()

People

(Reporter: TYLin, Unassigned)

References

Details

In bug 1758757, I expanded nsTableRowGroupFrame::SlideChild in its only callsite [1] in nsTableRowGroupFrame::ReflowChildren. However, I suspect the code is dead. Quote from my comment in phabricator [2]:

From the code coverage report, it looks like SlideChild is no-op. My theory is that whenever there is a dynamic change to nsTableRowGroupFrame or its nsTableRowFrame children's sizing , nsTableRowGroupFrame is going to reflow all the nsTableRowFrame children at once. It never reflows some dirty children while moves other non-dirty children. Therefore, any subsequent incremental reflow that is not dirty enough won't change any nsTableRowFrame's normal position, so we never enter the (oldPosition.B(wm) != newPosition.B(wm)) branch.

We can either remove the "// Move a child that was skipped during a reflow." branch, or figure out if it's possible to fix moving nsTableRowFrame in an incremental reflow.

[1] https://searchfox.org/mozilla-central/rev/5b2d2863bd315f232a3f769f76e0eb16cdca7cb0/layout/tables/nsTableRowGroupFrame.cpp#445
[2] https://phabricator.services.mozilla.com/D150323#4911680

Component: Layout → Layout: Tables
You need to log in before you can comment on or make changes to this bug.