Automatic update from web-platform-tests
[gap-decorations] Fix flex gap decorations crash in frag scenario
Currently, we keep a `fragment_relative_index` when we build gaps to
both determine when to build main gaps, as well as access "previous"
main gaps when processing a line in a non-ascending order.
We currently derive this index by simple subtraction, `flex_line_index
- first_flex_line_processed_index_`. However, as it turns out this ends
up breaking in a non-contiguous situation set like processing lines {0,
2, 3} in a fragment (line 1 finished earlier). This results in the
following relative line indices: 0, 2, 3, where it should be 0,1,2. This
creates issues with our vector indexing since we expect these indices to
be contiguous, and it also leads to issues because
`flex_cross_gap_sizes_` used an == guard to determine when to add to it,
and once the index jumped past the count, the equality could never hold
again, so the array froze one entry short. (i.e.
`gap_geometry_->GetFlexCrossGapSizeCount() ==
fragment_relative_line_index` would be false).
Now, we add a lazy map + counter that maps an absolute flex-line index
to a contiguous 0-based position assigned in visit order within the
current fragment.
This simplifies the current code, and also fixes this class of bugs.
A rendering test was added, it no longer crashes but technically has
some wrong behavior that we want to fix. Filed a bug and will address
that in another CL.
Fixed: 528865563
Bug: 532828232
Change-Id: Ieee7b594a85c69e03ef3f9692994ee685f315f76
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8021595
Commit-Queue: Javier Contreras <javiercon@microsoft.com>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1661164}
--
wpt-commits: 18e675aa9389ffa5461589b9caa8ca57312e2fb5
wpt-pr: 61214
Javier Contreras
b28dddfec2