1916147 - New wpt failures in /css/css-overflow/line-clamp/webkit-line-clamp-047.html

Status: NEW

(Core :: Layout: Floats, defect, P3)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Syncing wpt PR 47917 found new untriaged test failures in CI

Tests Affected

New Tests That Don't Pass

• /css/css-overflow/line-clamp/webkit-line-clamp-047.html [wpt.fyi]: FAIL (Chrome: PASS, Safari: FAIL)

CI Results

Gecko CI (Treeherder)
GitHub PR Head

Notes

These updates will be on mozilla-central once bug 1916142 lands.

Note: this bug is for tracking fixing the issues and is not
owned by the wpt sync bot.

This bug is linked to the relevant tests by an annotation in
https://github.com/web-platform-tests/wpt-metadata. These annotations
can be edited using the wpt interop dashboard
https://jgraham.github.io/wptdash/

If this bug is split into multiple bugs, please also update the
annotations, otherwise we are unable to track which wpt issues are
already triaged. Resolving as duplicate or closing this issue should
be cause the bot to automatically update or remove the annotation.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

I don't understand the comment in the test... What is it about our rendering that isn't reasonable? There's no fragmentation going on in legacy -webkit-line-clamp, so what is the comment about?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Err wrong florian, sorry :)

Comment 3

[Andreu Botella]

The way legacy -webkit-line-clamp is currently defined in the CSS Overflow spec, it is still a shorthand for continue: -webkit-discard and other properties, so the comment is referring to that fragmentation. With continue: collapse, the test also happens to work, and the float wouldn't fragment either way, so that comment would be irrelevant.

The reason Firefox fails this test is because, in continue: collapse (at least the way it's defined in my draft PR in https://github.com/w3c/csswg-drafts/pull/10816), any lines and other boxes after the clamp point should be hidden from paint, regardless of whether the line-clamp container has overflow: hidden. And in this test, the container purposefully doesn't set overflow: hidden.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Ok, thanks... so bug 1791226 would fix this.

Comment 5

[Andreu Botella]

Oh, there's another thing that Firefox is not currently doing, which is taking float clearance into account when determining the size of a line-clamp container. The height of the container should be the same as if it was a regular BFC without any line boxes or regular boxes after the clamp point. (I'll edit the continue: collapse PR to add a note making this clear.)

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Ok so I queued the dependent bug for landing, and I'm still a bit confused about comment 5.

which is taking float clearance into account when determining the size of a line-clamp container

You mean not taking float clearance into account? My expectation is that we clamp at the height of the line box, not the height of the float, which is what we do...