1687372 - -webkit-line-clamp clamps each flex item independently in Firefox, but it should clamp the lines of all flex items collectively (the way it works in WebKit-derived browsers)

Status: RESOLVED WORKSFORME

(Core :: Layout: Flexbox, defect)

Description

[Daniel Holbert [:dholbert]]

See https://github.com/webcompat/web-bugs/issues/65599 for the original issue here. But I'm also attaching a somewhat reduced testcase.

STR:

1. Load attached testcase.

EXPECTED RESULTS:
Three lines of text, ending with an ellipsis.

ACTUAL RESULTS:
Three lines of text, ending with an ellipsis... and then many more lines of text, with unreadable overlapping in some areas.

(EXPECTED RESULTS here are based on Chrome, which I'm using as a reference since we -webkit-line-clamp is non-standard & is just implemented for compat reasons.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (somewhat reduced)

Comment 2

[Emilio Cobos Álvarez (:emilio)]

So we're clamping the blocks individually, while chrome seems to clamp all the paragraphs after the first or something.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced)

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

So we're clamping the blocks individually, while chrome seems to clamp all the paragraphs after the first or something.

Yeah, that's what seems to be happening.

It looks like:

1. we're line-clamping each flex item individually, and letting their collective heights establish the height of the flex container (so the flex container is e.g. numFlexItems * 3 * line height, roughly)
2. we're doing the "overflow:hidden"-clipping at the granularity of the flex container
   ...which means that some of the overflow from the first flex item (after its 3 clamped lines) ends up being visible because the flex container is taller than it.

Part (2) seems like it may be the correct behavior, but part (1) probably needs fixing.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 3

Here's another testcase, where each flex item is only one line. This ends up meaning that we don't do any clamping at all (for reasons discussed above), whereas Chrome still clamps the content to 3 lines total.

EXPECTED RESULTS: this testcase should render three lines, with the third line being ellipsized: 3...
ACTUAL RESULTS: this testcase renders all 9 lines, and there's no ellipsis.

Comment 6

[Thomas Wisniewski [:twisniewski]]

The testcases do not fail for me on today's nightly build on my macbook, and www.francetvinfo.fr looks fine as well.

However, the fix range mozregression gave me looks suspect, so I'm not sure what fixed this: https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=136f13b75057ef4c2419dba0d63e913d502c7458

Still, closing as WORKSFORME.

Comment 7

[Daniel Holbert [:dholbert]]

You're hitting a mozregression bug, I think. When I run mozregression, it gives me this fix-range first, which is the correct one:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=49a271c42001f7bc5b9efadfc3e0b66dc0b67777&tochange=5caa044a10b8318931c12f5eb664f4b173243836

And then mozregression posts some warning-spew about failing-to-bisect further and then posting a warning because that failure somehow arrives at a single changeset being first-bad and also last-good, which it then represents as the exact single-changeset pushlog that you shared (notice no fromchange/tochange in that URL in comment 6).

Anyway -- in the correct push range, I think this would've been fixed by bug 1786147, probably (or perhaps bug 1789123).