Better box decoration cloning around monolithic content. (#47165)
Not a very important thing, but I discovered and fixed some
imperfections in the code while looking into this, which should be good
for health.
The correct thing to do for tall overflowing monolithic content: don't
clone box decorations of the container, since the container itself will
also become equally tall and monolithic in such cases.
In order for FinishFragmentation() to correctly understand when we're
past the block-end of a node, update space_left if there's monolithic
content inside forcing the node itself to use more space as well.
There's no spec to properly guide us here, but it should at least be
better now.
While working on this, I discovered that the overflow calculation code
in PhysicalBoxFragment::Create() got the wrong border / padding values -
i.e. any value that should be truncated wasn't. Fixing this also
required fixing the LayoutTableColumn implementation of offsetHeight &
co, since it was assuming that every fragment had the box decoration
stored, even when they were not part of the fragment. For now, only
truncate along the block axis. If we could also do the same to inline
decorations, we could probably remove SidesToInclude() from
PhysicalBoxFragment.
There's some fairly good inter-op with Gecko here, but one of the new
tests is failing in Blink (but I believe it's correct, and it should be
passing in Gecko).
Bug: 40415661
Change-Id: I95e8468c071d0a97aa12fc3823b26b17b02a7af6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5713315
Reviewed-by: Ian Kilpatrick ikilpatrick@chromium.org
Commit-Queue: Morten Stenshorne mstensho@chromium.org
Cr-Commit-Position: refs/heads/main@{#1328742}
Co-authored-by: Morten Stenshorne mstensho@chromium.org