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.)

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

(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.

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.