[Webkit-unassigned] [Bug 241800] New: Wrong image display for Non-integer sized elements and background-position specified as %

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=241800

            Bug ID: 241800
           Summary: Wrong image display for Non-integer sized elements and
                    background-position specified as %
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: CSS
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: webkitbugzilla at intensity.org.uk

Created attachment 460367

  --> https://bugs.webkit.org/attachment.cgi?id=460367&action=review

webkit rendering at 1x

If all of:

 * the size of an element has non-integer size in pixels,
 * `background-position` is specified as a percentage
 * `background-position` is specified in units of pixels

then webkit renders the wrong part of the background image.


Tested with 251689 at main, Safari Technology Preview Release 146 (Safari 15.4, WebKit 17614.1.14.10.6), Safari iPhone 15.5

This issue occurs in the production site boardgamearena.com - which is rather too complex to use as a demo, but in summary: many of the 400 games there draw their sprites incorrectly in Safari (desktop and mobile) because of this issue. 

Demo

1. Visit https://jsfiddle.net/shadowphiar/yLq36mzt/

Observe the results area in the bottom right. 

The four boxes are drawn by selecting a small area of a large background image (as one might do to combine many small icons into a single large image which is requested only once and cached). The boxes should each display the 125th square from a row of 126 squares. This is defined by a square div and a background-position: -12400% 0%;.
The left two boxes, the background-size is defined as a percentage (126 times the size of the displayed div). The right two boxes it is defined in pixels, calculated as 126 times the size of the displayed div. These should be the same size.
The top two boxes are drawn with a png image (fetched), the bottom two with an svg image (embedded in the css). The images are the same apart from file format.

Expected Result: There should be four identical orange boxes each with a white outline.

Actual Result:

Safari, including Safari Technology Preview Release 140 (Safari 15.4, WebKit 17614.1.1.5), display the boxes on the right incorrectly - the white border is somewhere in the middle of the square.

2. Open Chrome, or Microsoft Edge, and visit the same page. Observe that the four boxes look identical (or very close to being identical. The top right box may be off by a pixel or two).

3. Open Firefox and visit the same page. Observe the the top left and right boxes are displayed correctly. [But, for a different reason, the bottom boxes are wrong]

4. Back in Safari, enter responsive design mode and change the view between 1x, 2x and 3x modes. (Or drag the window from a Retina display to a non-retina external monitor).  Observe that the position of the white line inside the boxes changes. Observe that the card image below the boxes is incorrectly clipped, and shows another card’s artwork on the left or right side (on the right size at 1x, and on the left side at 2x)

Hypothesis:
This appears to occur when the size of the element is a non-integer number of pixels. It looks like Safari, when it calculates background-position or background-size property as a percentage of the element’s height or width, is rounding the div width to an integer.
If background-size is not specified with the same calculation path, and specifically one in which that rounding step did not occur, then the part of the image actually displayed can vary. At large percentages, half a pixel in the size of the div can result in really quite a significant difference in the portion of the image that gets displayed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220621/d043ec65/attachment.htm>