Test Results: https://wpt.fyi/results/css/css-backgrounds/border-image-slice-percentage.html

Testcase: http://wpt.live/css/css-backgrounds/border-image-slice-percentage.html
Reference: http://wpt.live/css/css-backgrounds/reference/border-image-repeat-round-ref.html

Chrome passes this test; Firefox and Safari both fail. However, for what it's worth, we "pass" in terms of the textual description in the test:

<meta name="assert" content="diamonds in corners should be red, and other diamonds should be orange, it should be 4 orange diamonds on each side.">

(Safari does not pass, by that criteria; they show 2 orange diamonds on each side.)

Firefox's rendering-difference between the testcase & reference case is noticeable but subtle; the diamonds have a very slightly different position -- they're shifted "outwards" by ~1px. We fail with these fuzzy metrics:

maxDifference: 122
totalPixels: 2920

The test is annotated as fuzzy, but the fuzzy-threshold is too low to allow for our level of difference (particularly the maxDifference component):

   <meta name="fuzzy" content="0-7; 0-944">

Needs some further analysis to see to-what-extent the test is overconstrained, vs. if there's a real bug here.

This one looks essentially the same:
https://wpt.fyi/results/css/css-backgrounds/border-image-space-001.html

This one, we fail with:

maxDifference: 38
totalPixels: 3520 

...which is over the threshold encoded in the test:

<meta name="fuzzy" content="0-12; 0-1152">

Again, Safari fails with a more-substantial difference, only showing 2 orange diamonds on each side.

Daniel,

I will be eventually submitting the following to WPT as they will not require any fuzzy correction or fuzzy-threshold.

Test:
http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/border-image-repeat-space-011.html

Reference:
http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/reference/border-image-repeat-space-011-ref.html

Firefox 102.9.0 ESR and Chromium 111.0.5563.110 pass this test.

Epiphany 3.38.2 (using WebKitGTK 2.38.5) fails this test.

Thanks, that's good to hear! That looks like a version of the other tests but with solid-color blocks. I had been wondering whether that sort of adjustment would address fuzziness here, and it's good to see that it does.

(I'm assuming the other tests mentioned in earlier comments here will remain in the WPT suite and will continue to use their "diamonds" border-image; if so, then I'll still want us to add some fuzzy annotations to them, to avoid them spuriously showing up as failing for un-interesting reasons.)

Daniel,

I read for the first time your comment #c3. I did not get a bugzilla email about it.

I am waiting for a reviewer in

Created a reliable, trustworthy border-image-repeat-space test
https://github.com/web-platform-tests/wpt/pull/39444

so that such test can be submitted. There is no chance of anti-alias fuzziness if an image does not contain oblique "/" or "\" lines in it. A lot of WPT border-image related tests use diamond shape images and I now think this is wrong.

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

I am waiting for a reviewer in

Created a reliable, trustworthy border-image-repeat-space test
https://github.com/web-platform-tests/wpt/pull/39444

Note, this pull request has since been merged (hooray)!

And the fuzzy thresholds of the tests that this bug was filed for (comment 0, comment 1) have been adjusted by WebKit folks (in https://github.com/web-platform-tests/wpt/commit/51a82f5eaa3c39528daf4e52bf33925be7a30c83 ) such that we now pass (i.e. we're within the allowed tolerance).

So all issues here have been fixed (upstream).