Handle cloned box decorations in flex containers.
Don't assume that items resume at block-offset in a flex container
fragment after a break. There may be cloned box decorations there. Just
use BorderScrollbarPadding(). If box decorations are to be sliced, they
will be 0 there.
Also only use BorderPadding() when resolving the total node size, since
cloned box decorations are multiplied there. Use
BorderScrollbarPadding() in call to FinishFragmentation().
Items in flex containers are distributed before fragmentation, and then
adjusted afterwards. If fragmentation inserts cloned box decorations on
the flex container, we need to compensate for that when dealing with
values based on unfragmented layout. We need something almost like
"previously consumed block-size", but not quite. Previously consumed
block-size of a flex container includes any cloned box decorations, but
they are not part of the imaginary unfragmented flex container. This is
what offset_in_stitched_container is about.
GiveItemsFinalPositionAndSizeForFragmentation() will now use that one
instead of previously_consumed_block_size in almost all cases, except
those that are about sizing the container itself.
Since cloned box decorations effectively grows the border box size of a
node each time it fragments, the block-size of items in a flex column
flow needed s\some adjustments. Since the flex algorithm is responsible
for calculating the block-size of an item, it is fixed/locked for the
child layout algorithm, which means that flex items (unlike children in
a regular block container) may not resolve their own block-size. We
therefore need to adjust it every time the item breaks.
Bug: 40415661
Change-Id: I604b937898db75e0b0d86731410562f848ed1307
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5717758
Commit-Queue: Morten Stenshorne mstensho@chromium.org
Reviewed-by: Ian Kilpatrick ikilpatrick@chromium.org
Cr-Commit-Position: refs/heads/main@{#1329733}