Closed Bug 1913486 Opened 3 months ago Closed 3 months ago

[wpt-sync] Sync PR 47643 - [line-clamp] Take ruby annotations into account for `line-clamp: auto`

Categories

(Core :: Layout: Scrolling and Overflow, task, P4)

Product:
Core
Component:
Layout: Scrolling and Overflow
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
131 Branch
Tracking Flags:
Tracking Status
firefox131 --- fixed

People

(Reporter: wpt-sync, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [wptsync downstream])

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

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

Andreu Botella <abotella@igalia.com> wrote:

[line-clamp] Take ruby annotations into account for line-clamp: auto

When line-clamp: auto is being used, it should clamp at the last
point where the size of the box would not go beyond its specified
max-height. However, this did not always hold when there were
line-under ruby annotations on the lines around the clamp point.

This happens because the annotation overflow that such annotations
create increases the height of the line, but this overflow size (which
is tracked in PreviousInflowPosition) will be subtracted from any
immediately following padding. Since line-clamp: auto tracks padding
by subtracting the block end padding in a box from its parent's clamp
offset, this results in accounting for the pull padding and the full
annotation overflow. This patch fixes that by passing the current
box's block end padding into BlockLineClampData::UpdateAfterLayout
to account for that.

Another bug with ruby and line-clamp: auto is that the last line
before the clamp point might not have an ellipsis, or lines before the
clamp point might end up hidden if they had ruby annotations. This is
because whether a line has an ellipsis or is hidden needs to be
computed before the layout of that line finishes. And for
line-clamp: auto, whether a line is at the clamp point or after it
depends on its height, which is dependent on the line's annotations.
Furthermore, here the annotation overflow also needs to be accounted
for, relative to the block container's block end padding.

To fix this, this patch merges the ShouldLineClamp and
ShouldHideLine methods from InlineLayoutAlgorithm into a single
GetLineClampState method. In this method, when we are clamping by a
height, we precompute the line's effective total block size. And since
we also need to account for the effects of padding afterwards, we add
a LineClampEndPadding field in the constraint space to pass it as an
input.

Bug: 40336192
Change-Id: I90fb500dc79a7ed669fa1a74e5bfdc43a26a7447
Reviewed-on: https://chromium-review.googlesource.com/5785842
WPT-Export-Revision: 56fb91a28c9971c745f48b9a232dadf4a6765e8c

Component: web-platform-tests → Layout: Scrolling and Overflow
Product: Testing → Core

CI Results

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

Total 6 tests

Status Summary

Firefox

FAIL: 6

Chrome

PASS: 3
FAIL: 3

Safari

FAIL: 6

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

New Tests That Don't Pass

Pushed by wptsync@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f44885a9b465 [wpt PR 47643] - [line-clamp] Take ruby annotations into account for `line-clamp: auto`, a=testonly https://hg.mozilla.org/integration/autoland/rev/0c5be8996386 [wpt PR 47643] - Update wpt metadata, a=testonly

https://hg.mozilla.org/mozilla-central/rev/f44885a9b465
https://hg.mozilla.org/mozilla-central/rev/0c5be8996386

Status: NEW → RESOLVED
Closed: 3 months ago
status-firefox131: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 131 Branch
You need to log in before you can comment on or make changes to this bug.