tree 8980535d679e0ec20556253ee52a29d0296b2d56
parent 90925c90d97732e91ba03c845b9afa7eee727ac4
author David Grogan <dgrogan@chromium.org> 1563061595 -0700
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> 1563062207 -0400

[LayoutNG] Honor table cell descendants' min heights

LayoutNG ignored them for row height sizing (Measure phase) when the
descendant had a % height and overflow auto/scroll.

The fix turned out to be simple but getting there was not.

I think our existing NG behavior was correct according to the spec, but
if my interpretation is correct, the spec is missing this case.

https://drafts.csswg.org/css-tables-3/#row-layout :
For the purpose of calculating this height, descendants of table cells
whose height depends on percentages of their parent cell' height (see
section below) are considered to have an auto height if they have
overflow set to visible or hidden or if they are replaced elements, and
a 0px height if they have not.

In these test cases the descendants of table cells' heights do depend on
their parent cell' height and have overflow set to neither visible nor
hidden, so should get 0. (They depend on their parent's height because
the descendant height is max(resolved min-height, resolved height) where
resolving height needs the cell height.)

But sizing the row such that the descendants don't fit doesn't make
sense (and isn't what engines do today). This was happening in NG when
the min-height of the descendant was larger than the height of the row,
after calculating the height of the row by indiscriminately using 0px as
the height contribution from % height scroller descendants.

The fix is to use % height scroller descendants' min heights as their
contribution to the row height instead of 0px.

We still get a related case wrong in legacy and NG
(percentage-sizing-of-table-cell-children-005.html) -- when a scroller
descendant has % height but the cell height is indefinite, we should
treat the descendant's % height as auto, per css2, even for row sizing
purposes. Instead, we currently treat it as a % height such that it
contributes 0px to the height instead of its post-layout height.

I also discovered some suspected dead code that used to have some of
this relayout-depending-on-scrolling logic.

Bug: 982323, 982312
Change-Id: Iff5210f6bf53c8f7e4b29ca32f8401d0eb738317
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1700782
Commit-Queue: David Grogan <dgrogan@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#677211}