Closed Bug 1961751 Opened 1 year ago Closed 1 year ago

[wpt-sync] Sync PR 52074 - [line-clamp] Fix bugs detecting whether a line is the last in the IFC

Categories

(Core :: CSS Parsing and Computation, task, P4)

Product:
Core
Component:
CSS Parsing and Computation
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
139 Branch
Tracking Flags:
Tracking Status
firefox139 --- fixed

People

(Reporter: wpt-sync, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 52074 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/52074
Details from upstream follow.

Andreu Botella <abotella@igalia.com> wrote:

[line-clamp] Fix bugs detecting whether a line is the last in the IFC

In https://crrev.com/c/6361775, we fixed a bug in the implementation
of ellipsis during line-breaking by detecting whether an ellipsized
line would be the last line in the IFC if it wasn't ellipsized. That
involved doing a fast check of the remainder of the IFC content, and
if that check was inconclusive, the line breaking was done again
without ellipsizing.

However, that fast check contained assumptions that held for the
implementation of ellipsis during line-breaking when that CL landed.
And since then https://crrev.com/c/6394977 and
https://crrev.com/c/6395136 have landed, which allow an ellipsized
line to break in places that wouldn't be possible with no ellipsis,
including at the start of the line. This makes some of the assumptions
in that first CL wrong.

This fixes this by taking into account whether the breakpoint chosen
when ellipsizing would have been a valid breakpoint otherwise, and by
taking into account whether an item allows text wrapping when trying
to see if the rest of the IFC's content fits. In cases where the
ellipsis breakpoint is not valid without it, but where the rest of
items in the IFC might still have valid breakpoints, in many cases we
would fall back to the slow path.

This CL also fixes a bug with the slow path, where due to reusing the
existing LineBreaker, it was not redoing the line breaking of the
current line, but instead line breaking the next line. We fix this by
creating a new LineBreaker instance in that case.

This CL also fixes some block-ellipsis tests that expected the wrong
behavior since the were written against buggy CLs that are fixed in
this patch.

Bug: 40336192
Change-Id: I9d3302b13a65a0054e8a386a162cb3794caee932
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6464231
Commit-Queue: Andreu Botella \<abotella@igalia.com>
Reviewed-by: Koji Ishii \<kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1449389}

Whiteboard: [wptsync downstream] → [wptsync downstream error]
Component: web-platform-tests → CSS Parsing and Computation
Product: Testing → Core
Whiteboard: [wptsync downstream error] → [wptsync downstream]

CI Results

Ran 7 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 6 tests

Status Summary

Firefox

FAIL: 6

Chrome

PASS: 2
FAIL: 4

Safari

PASS: 1
FAIL: 5

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

Firefox-only Failures

New Tests That Don't Pass

Pushed by wptsync@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bffb9e012b2c [wpt PR 52074] - [line-clamp] Fix bugs detecting whether a line is the last in the IFC, a=testonly https://hg.mozilla.org/integration/autoland/rev/0f709ce46cb1 [wpt PR 52074] - Update wpt metadata, a=testonly

https://hg.mozilla.org/mozilla-central/rev/bffb9e012b2c
https://hg.mozilla.org/mozilla-central/rev/0f709ce46cb1

Status: NEW → RESOLVED
Closed: 1 year ago
status-firefox139: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 139 Branch
You need to log in before you can comment on or make changes to this bug.