Bug 155955 – border-image-repeat:round output doesn't match other browsers

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Chris Rebert]

Created attachment 275046 [details]
Screenshot from WebKit Nightly r198607

(Tested in OS X WebKit Nightly r198607 and in iOS 9.3)

Steps to reproduce:
1. Open http://output.jsbin.com/weqiqu/quiet in WebKit/Safari.
2. Note that the page's CSS uses `border-image-repeat: round round;` for the border in question.
3. Observe the red, blue, and transparent border.

Expected result:
Each segment of red, blue, and transparency in the border should be relatively short.
(See attached screenshots from other browsers)

Actual result:
Each segment of red, blue, and transparency in the border is relatively long, roughly twice as long as in the other browsers.
(See attached screenshot from WebKit Nightly)

[Chris Rebert]

Created attachment 275047 [details]
Screenshot from Firefox 47

[Chris Rebert]

Created attachment 275049 [details]
Screenshot from Chrome 49

[Chris Rebert]

See also: https://github.com/Fyrd/caniuse/issues/2366

[Alexey Proskuryakov]

<rdar://problem/28213711>

[Simon Fraser (smfr)]

We fail to implement the "and their width is scaled proportionally" bit of https://www.w3.org/TR/css3-background/#border-image-process.

Fixing this and the rendering of the middle part of the image requires hoisting the tiling mode logic out of Image::drawTiled() and up into NicePieceImage.

[Adenilson Cavalcanti Silva]

If this one is available, I would like to work on it.

[Simon Fraser (smfr)]

Please do. I started looking at this and it's a bit more involved than I thought.

Basically I think the fix should reflect this comment in Image::drawTiled():
    // FIXME: These rules follow CSS border-image rules, but they should not be down here in Image.

so the 'space' and 'round' logic there needs to pushed up into NinePieceImage::computeTileScales(), maybe as part of scaleSlicesIfNeeded(). This probably requires sending 'spacing' and 'phase' down through GraphicsContext::drawTiledImage(). I think this code move is necessary to implement this part of the spec:

"The middle image's width is scaled by the same factor as the top image unless that factor is zero or infinity, in which case the scaling factor of the bottom is substituted, and failing that, the width is not scaled. The height of the middle image is scaled by the same factor as the left image unless that factor is zero or infinity, in which case the scaling factor of the right image is substituted, and failing that, the height is not scaled."

[len]

Is this still not fixed?  I'm still seeing this issue in 2021, 5.5 years after this was reported.  

https://stackoverflow.com/questions/68896770/border-image-slicing-differences-between-browsers

[Ahmad Saleem]

I am able to reproduce this bug in Safari Technology Preview 152 using attached JSBin from URL field and the border does not match with other browsers (Chrome Canary 107 and Firefox Nightly 106).

Just wanted to share updated testing results. Thanks!

[Brent Fulgham]

(In reply to Simon Fraser (smfr) from comment #7)
> Please do. I started looking at this and it's a bit more involved than I
> thought.
> 
> Basically I think the fix should reflect this comment in Image::drawTiled():
>     // FIXME: These rules follow CSS border-image rules, but they should not
> be down here in Image.
> 
> so the 'space' and 'round' logic there needs to pushed up into
> NinePieceImage::computeTileScales(), maybe as part of scaleSlicesIfNeeded().
> This probably requires sending 'spacing' and 'phase' down through
> GraphicsContext::drawTiledImage(). I think this code move is necessary to
> implement this part of the spec:
> 
> "The middle image's width is scaled by the same factor as the top image
> unless that factor is zero or infinity, in which case the scaling factor of
> the bottom is substituted, and failing that, the width is not scaled. The
> height of the middle image is scaled by the same factor as the left image
> unless that factor is zero or infinity, in which case the scaling factor of
> the right image is substituted, and failing that, the height is not scaled."

I think the logic in NinePieceImage::computeMiddleTileScale(...) correctly addresses the above (at east for zero -- not sure if Infinity ever gets this far).

I believe I've found a calculation error. Patch coming.

[Brent Fulgham]

Pull request: https://github.com/WebKit/WebKit/pull/11668

[EWS]

Committed 261903@main (255da9f55bbe): <https://commits.webkit.org/261903@main>

Reviewed commits have been landed. Closing PR #11668 and removing active labels.

[Brent Fulgham]

See also: https://github.com/web-platform-tests/wpt/pull/39123

[Ahmad Saleem]

*** Bug 229803 has been marked as a duplicate of this bug. ***

[Brent Fulgham]

*** Bug 254843 has been marked as a duplicate of this bug. ***

[Alexandr Shushunov]

It looks like the bug still exists.

[Alexandr Shushunov]

Created attachment 471846 [details]
Chrome 126

[Alexandr Shushunov]

Created attachment 471847 [details]
Safari 16.2

[Alexey Proskuryakov]

Safari 16.2 is very old, it shipped before the fix. Can you reproduce with Safari 17 or newer?

[Alexandr Shushunov]

My mistake. It works correctly in Safari 17.