Bug 1769760 [wpt PR 34093] - Fix a bug with calculation of ShapeResultView's previous...

Bug 1769760 [wpt PR 34093] - Fix a bug with calculation of ShapeResultView's previous safe offset, a=testonly

Automatic update from web-platform-tests
Fix a bug with calculation of ShapeResultView's previous safe offset

A ShapeResultView's previous safe to break offset used to be
calculated by assuming that a part's first character corresponds to
the part's start index. For LTR text, however, the start index is
often, if not always, 0, meaning that for ShapeResultViews which start
at some non-zero index into the text (such as for lines in a paragraph
other than the first), the returned previous safe offset could be much
earlier than it should, or it could even be before the start of the
view.

Since NGLineBreaker::TruncateLineEndResult uses the previous safe
offset to determine which parts of a new line to reshape, if the
returned safe offset happens to be in the range of the view and in the
middle of a ligature, the first character in the ligature would not be
reshaped and would thus be set to the ligature glyph, while the
characters after the returned safe index would be reshaped and be set
to their corresponding glyphs. This leads to the appearence of the
characters after the offset being repeated.

This was fixed by changing `run_start` to be the part's start index
plus the view's char index offset.

Bug: 1304876
Change-Id: Ied68dd5986b603814fa236e7ab2081db5a817723
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3644742
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Andreu Botella <abotella@igalia.com>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1006370}

--

wpt-commits: 4a89b60bd822e06cb0e5a2bc6792019ccde05531
wpt-pr: 34093