1819485 - border-image-slice with 'fill' keyword draws top left of middle region when it should draw center of middle region

Status: RESOLVED DUPLICATE of bug 1778032

(Core :: Graphics: WebRender, defect)

Description

[Gérard Talbot]

Info:

Issue 38586: [border-image-slice] 'fill' keyword and preserving middle part of border-image
https://github.com/web-platform-tests/wpt/issues/38586

Pull request 38756: Added 3 new border-image-slice-fill tests and related references
https://github.com/web-platform-tests/wpt/pull/38756

Tests and references:

http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/border-image-slice-fill-001.html

http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/border-image-slice-fill-002.html

http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/border-image-slice-fill-003.html

http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/reference/border-image-slice-fill-001-ref.html

http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/reference/border-image-slice-fill-002-ref.html

http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/reference/ref-filled-green-100px-square.xht

Excerpts from specifications:

CSS3 Backgrounds, § 5.5 Image Tiling: the border-image-repeat property states
"
The first keyword applies to the horizontal scaling and tiling of the top, middle and bottom parts, the second to the vertical scaling and tiling of the left, middle and right parts (...)
If the second keyword [regarding border-image-repeat] is absent, it is assumed to be the same as the first.
"
https://www.w3.org/TR/css-backgrounds-3/#border-image-repeat

CSS3 Backgrounds, § 5.6 Drawing the Border Image, parg 3 states:
"
Position the first tile.
If the first keyword is repeat, the top, middle, and bottom images are centered horizontally in their respective areas. (...)
If the second keyword is repeat, the left, middle, and right images are centered vertically in their respective areas.
"
https://www.w3.org/TR/css-backgrounds-3/#border-image-process

These tests fail in both Firefox 102.8.0esr and Firefox 112.0a1 buildID=20230228085339 .

These tests pass in Chromium 110.0.5481.177 and Epiphany 3.38.2 (using WebKitGTK 2.38.5) .

+CC: Emilio

testcase keyword added

Comment 1

[Emilio Cobos Álvarez (:emilio)]

These used to work. I bisected and I got this range back: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=404680ad41e4e7d08aa46081a70095486f14e15f&tochange=e704e3565db9260efaa854f2916ca023b717db3c

Which includes bug 1564907 which enabled WebRender for me. Bisecting with WebRender force-enabled gets me this range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=50fec259d5a66e44a087253fa5f9f805d32e8ef3&tochange=404680ad41e4e7d08aa46081a70095486f14e15f

Which strongly suggests bug 1409773 as the regressor.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1409773

:aosmond, since you are the author of the regressor, bug 1409773, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 3

[Timothy Nikkel (:tnikkel)]

This seems more like an S3 then an S2. I'm assuming S2 was set because the less specific bug title made it sound like we didn't implement the fill keyword at all here (but we do, just the positioning is off).

Comment 4

[Timothy Nikkel (:tnikkel)]

ni Jeff in case I missed a reason why this is S2

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1409773

Comment 6

[Daniel Holbert [:dholbert]]

Note: per https://github.com/web-platform-tests/interop/issues/314 , the border-image-slice-fill-* tests are soon-to-be included in interop2023.

Comment 7

[Gérard Talbot]

WPT Test result:
https://wpt.fyi/results/css/css-backgrounds?q=border-image-slice-fill-0

Comment 8

[Daniel Holbert [:dholbert]]

Looking at wpt.fyi results for just Chrome & Firefox (to see most recent runs which Safari/Edge didn't complete for whatever reason), it looks like we now pass the -001 test, but still fail -002 and -003.

i.e. this shows "pass":
https://wpt.fyi/results/css/css-backgrounds/border-image-slice-fill-001.html?label=master&label=experimental&product=chrome&product=firefox&aligned

...but this still shows "fail" (and the failure looks the same as it did before -001 started passing):
https://wpt.fyi/results/css/css-backgrounds/border-image-slice-fill-002.html?label=master&label=experimental&product=chrome&product=firefox&aligned
https://wpt.fyi/results/css/css-backgrounds/border-image-slice-fill-003.html?label=master&label=experimental&product=chrome&product=firefox&aligned

First one was probably fixed by bug 1778032, and the other two still need a distinct fix, I guess.

Comment 9

[Daniel Holbert [:dholbert]]

I'll attach some modified-for-diagnosis versions of the still failing tests (border-image-slice-fill-002.html and -003), for archival and to get a little closer to understanding what's going wrong.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: (image for use in testcase)

First, here's the image to be used in the attached testcases. It's a modified version of the WPT one:
http://wpt.live/css/css-backgrounds/support/500x500-red-with-green-center.png

(I've modified the original to fill in the blank outer edge with various colors, so that we can see a bit better when we're drawing border-image portions from those areas of the image.)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: (image for use in testcase)

(Actually, I'm making one additional change to the image -- I'm adding a cyan circle inside the green square. This helps to visually distinguish between drawing-the-whole-green-square (with the circle and all) vs. just sampling and tiling some smaller portion of the green square.)

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 2a (variant of border-image-slice-fill-002.html, just using a different image)

Here's a variant of this WPT:
http://wpt.live/css/css-backgrounds/border-image-slice-fill-002.html

On my system, Firefox Nightly draws a maroonish-brown color in the center of the yellow here, while Chrome draws the green square with a cyan circle.

The only pixel in actual image that is maroonish-brown is the extreme bottom-right corner of the image; so we're apparently sampling that one final pixel from the image and using it to fill the center region.

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 2b (now with border-width being 1px instead of 50px)

Here's another testcase where the border-width is 1px instead of 50px (and I've removed the yellow area and descriptive text for convenience).

Firefox and Chrome each render this similarly to how they render testcase 2a. Firefox still samples the maroon-colored pixel at the extreme bottom-right-most corner, and fills the content-area of the div with that; while Chrome samples the actual center of the image (the cyan circle in the green square)

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: testcase 2c (now with border-width **and** border-image-slice using 1) [This one renders interoperably]

Building on testcase 2b: if I additionally change border-image-slice to use 1 (i.e. 1px inset into the image on all sides), then we change to match Chrome - we draw the cyan circle in a green square over the content-area, and we draw the image's outermost 1px edge over the the border area.

In other words: it looks like we're interoperable on this version of the testcase. It's only when border-image-slice has 0 where we seem to run into trouble and do the pathological-looking thing of sampling from the extreme bottom-right-most pixel.

Comment 15

[Gérard Talbot]

(In reply to Daniel Holbert [:dholbert] from comment #10)

fill in the blank outer edge with various colors, so that we can see a bit better when we're drawing border-image portions from those areas of the image.)

Yes. This is indeed a good idea.

(In reply to Daniel Holbert [:dholbert] from comment #11)

I'm adding a cyan circle inside the green square. This helps to visually distinguish between drawing-the-whole-green-square (with the circle and all) vs. just sampling and tiling some smaller portion of the green square.)

Yes. This is another good idea.

(In reply to Daniel Holbert [:dholbert] from comment #12) regarding testcase 2a attachment 9354658 [details]

On my system, Firefox Nightly draws a maroonish-brown color in the center of the yellow here, while Chrome draws the green square with a cyan circle.

When trying attachment 9354658 [details] (tescase 2a) on my Linux Debian 12.1 system, Firefox nightly 119.0a1 buildID=20230922092201 draws a cyan square in the center of the yellow. No green drawn. No maroonish-brown color drawn.

(In reply to Daniel Holbert [:dholbert] from comment #13) regarding testcase 2b attachment 9354661 [details]

Firefox still samples the maroon-colored pixel at the extreme bottom-right-most corner, and fills the content-area of the div with that

When trying attachment 9354661 [details] (tescase 2b) on my Linux Debian 12.1 system, Firefox nightly 119.0a1 buildID=20230922092201 draws a cyan square. No maroon color drawn.

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Gérard Talbot from comment #15)

Yes. This is indeed a good idea.
Yes. This is another good idea.

Thanks! :) (Though to be clear, I don't at all think we should make those changes to the upstream WPT, since they're potentially introducing potential for fuzzy-mismatches. They're just an aid for diagnosis/understanding the particular bug here.)

When trying attachment 9354658 [details] (tescase 2a) [...and...] (tescase 2b) on my Linux Debian 12.1 system, Firefox nightly 119.0a1 buildID=20230922092201 draws a cyan square. No maroon color drawn.

Interesting! I see that too, if I force Firefox nightly to use software webrender. (setting gfx.webrender.software to true). So this is a difference between hardware WebRender and software WebRender, with both being wrong in different ways. :)

(You are probably getting Software WebRender due to us running into some sort of compatibility or driver issue. Diving into that would be off-topic for this bug, but it's not unusual, and you can learn more about what's happening by checking the Graphics section of about:support.)

Comment 17

[Daniel Holbert [:dholbert]]

So for Software WebRender, we seem to be sampling the antialiased color from a "virtual pixel" at the exact center of the image (which happens to be a vertex in a grid of the centermost 4 pixels), and then we use that color to fill the content-area. Per comment 15-16, that produces cyan right now. But if I edit the image locally so that the 4 center pixels are two black and two white (checkerboard-style), then testcases 2a and 2b render with gray instead of maroon or cyan (the antialiased average of that 4-pixel-checkerboard), in a Nightly build using software WebRender.

So: both hardware-WebRender and software-WebRender are selecting a single extreme pixel to use to determine a fill color for the content area; and they just happen to be selecting a different extreme pixel (final bottom-right pixel vs. exact-center.)

Comment 18

[Daniel Holbert [:dholbert]]

Attachment: testcase 3a

And for completeness, here's an expanded version of border-image-slice-fill-003.html, the other test that we're still failing here, mentioned in comment 8.

The actual -003 WPT test is just testing the scenario in the 3rd square in the bottom row here (the one with border-image-repeat:repeat and border-image-slice: 100 fill); but I've expanded out from there to exercise other border-image-slice values, and to test with/without border-image-repeat:repeat.

Right now, Firefox Nightly renders all of the divs identically here -- we're rendering the entire border-image as if it were the background-image for the content area, essentially, regardless of the varying styles. (This is how we behave with both software and hardware WebRender).

Blink and WebKit render this quite differently, though. They render the top row with progressively-more-zoomed-in snippet of the image; and they render the first four images in the bottom row as being the central squared-circle section of the image, and then two that are transformed in some way to be zooming in further. And they show the final item in each row (the one with border-image-slice: 250) as being blank, presumably because that's slicing away the whole image.

Comment 19

[Daniel Holbert [:dholbert]]

Regression range notes for the most recent changes to the testcases here (testing using hardware webrender):

• testcase 2a and 2b: our most recent change was via bug 1655717. Before that, we filled the content-area with orange, presumably sampling from the image's top-left corner pixel. After that, we fill the content area with maroonish, sampling from the bottom right corner pixel.

• testcase 2c: our most recent change (to its current good/interoperable behavior) was via bug 1778032 (which is also what fixed the -001 variant of the WPT test per comment 8). Before that, we rendered the top-left corner of the image in the content area; now we render the center (the squared circle chunk) which matches other browsers.

• testcase 3a: For this one, we used to render it much closer to other browsers -- we 100% matched current Blink/WebKit on the top row where border-image-repeat is left at its initial value; and on the rightmost four boxes in the bottom row, aside from a slight alignment difference in the s205 div there). But we changed to our current behavior of rendering all of the squares identically in the following pushlog, probably due to bug 1606771:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ed735c504092d21e78ecf5cb4debf5faecb4c4ab&tochange=fb6b61e49217d835b2d6e435560424aab10d5475

Given the above, I suspect we've got at least two distinct bugs here for the -002 vs. -003 WPT tests (and those bugs don't match what's described in the bug title here); so I'll probably spin them off as new separate bugs, and we can morph this bug here to cover the -001 testcase which I think the title does accurately describe and which is fixed per comment 8.

Comment 20

[Daniel Holbert [:dholbert]]

I spun off bug 1854733 and bug 1854737 for the -002 and -003 WPTs here. Let's focus this one on the -001 WPT and call it fixed, per last paragraph of comment 19.

Comment 21

[Daniel Holbert [:dholbert]]

(and -001 was fixed by bug 1778032, so let's dupe there I guess.)