1834648 - WPT failures in css/css-masking/clip-path/clip-path-inline-001.html and 002 and 003

Status: NEW

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

We fail these 3 tests, which are part of the interop-2023 CSS Masking suite:
https://wpt.fyi/results/css/css-masking/clip-path/clip-path-inline-001.html
https://wpt.fyi/results/css/css-masking/clip-path/clip-path-inline-002.html
https://wpt.fyi/results/css/css-masking/clip-path/clip-path-inline-003.html

They all have a clip-path applied to an element with display:inline (implicitly, by being a span). Tests -002 and -003 have a vertical writing mode, too.

The devtools visualization of the clip-path looks like it's in the right place, but we're not actually letting anything paint through it, it looks like. Also, in the -002 test, we paint some content from outside of it (a little strip of red to the left), which looks like we are doing some clipping but we're doing it in the wrong coordinate space, or something.

Comment 1

[Boris Chiou [:boris]]

I'm trying to figure out what is the expected behavior. These tests were added in https://github.com/web-platform-tests/wpt/pull/13318.

Per its comment, Blink uses the first fragment to compute its reference box for the container (because there are multiple lines inside this container (non-atomic inline) and so its shape is not a rectangle). And it looks like Gecko uses the first fragment as well.

The spec doesn't define this case for clip-path (and it mentions inline boxes only in mask-origin section). So I'm OK with this behavior. However, Gecko doesn't use the correct x coordinate (because there is another inline box before the first line, but we clip on it), so we fail this test. Also, the PR mentioned we don't handle different writing mode properly in this case.

BTW, it seems WebKit also takes the 2nd fragment into account. Perhaps it's more preferable.

Updated:
After changing the basic-shape we used (e.g. use circie() instead), it seems we clip each fragment separately by their coordinates (by using the size of each frame), and we don't merge them well. Blink and WebKit clip the both fragments and they look much better.
I suspect we have the similar issue for mask image as well.