1852291 - Trivial CSS transform values cause pixel-snapping logic to produce a different rendered size for elements with fractional-display-pixel size and position

Status: NEW

(Core :: Web Painting, defect)

Description

[shouu6]

Attachment: 스크린샷 2023-09-09 오전 12.20.26.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

<!DOCTYPE html>
<html>
  <head>
    <style>
      body {
        margin: 0;
      }
      div.container {
        width: 100vw;
        height: 100vh;
        background-color: black;

        display: flex;
        flex-flow: column nowrap;
        align-items: center;
        justify-content: center;
      }

      div.upper {
        flex: 0 0 2rem;
        height: 2rem;
        width: 90%;
        background-color: #0e7490;
      }
      div.lower {
        flex: 0 0 2rem;
        width: 90%;
        background-color: #be185d;
        transform: translate(0);
      }
    </style>
  </head>
  <body>
    <div class="container">
      <div class="upper"></div>
      <div class="lower"></div>
    </div>
  </body>
</html>

Actual results:

In a centrally aligned flexbox, the size of the child element appears to change even when using 'translate(0),' which normally shouldn't alter its dimensions.

This behavior is consistent not only with 'translate3D' but also with 'translateX,' 'translateY,' and 'translateZ.'

For instance, when the child element has a width of 90%, applying 'translate(0)' seems to shrink the element, while with a width of 99%, it appears to elongate.

This discrepancy is presumed to be a rendering issue, as the measurements obtained using developer tools remain consistent.

Comment 1

[shouu6]

The second sentence is a mistranslation. This issue does not occur with 'translate3d'.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from reporter)

Thanks for the bug report!

Here's a live version of the reporter's testcase from comment 0.

Using this testcase, I'm not seeing any difference locally between Firefox 117 and Chrome 116, when viewing them side-by-side on macOS. (In the reporter's screenshot, the testcase looks clearly taller in Firefox than in Chrome, but it's not on my machine).

The only way that I can reproduce something that looks like the screenshot is by using "pinch zoom" (i.e. while hovering the testcase, touch two fingers to my touchpad, and spread them apart).

Reporter, is there any chance that you may have done that by accident? (Note that pinch-zoom persists on reload, so you have to hold "Shift" when reloading if you want to reset the pinch-zoom state. Or restarting Firefox seems to reset it as well.)

If the bug persists even after restarting Firefox or resetting pinch-zoom state: could you test whether the bug persists in a fresh Firefox profile? (Visit about:profiles, click "Create a new profile", and follow the prompts and then click "Launch profile in new browser" for the new one.)

(Note, the newly-created Firefox profile will become your default profile automatically, so you'll also want to go back to about:profiles once you're done and click "Set as default profile" on the entry for your original profile.)

Thanks!

Comment 3

[shouu6]

Attachment: 스크린샷 2023-09-12 오후 9.40.48.png

When the window occupies the left half of the screen, and then drag the window edge to the right, the top blue line smoothly changes its size along 90% of the viewport width.

However, the red line below, which has 'translate(0)' applied, has certain points where its length either decreases or increases compared to the blue line as it gets larger.

This issue occurs independently of user profiles or pinch-zoom and can be confirmed by zooming in on screenshots taken without any zoom applied.

Because the difference is quite subtle, it requires careful attention.

I have confirmed that this problem does not occur in Safari and Chrome.

Comment 4

[Daniel Holbert [:dholbert]]

I see. So the issue that you're reporting is that the pink line and the teal line render with slightly different widths, at certain window sizes. Is that correct?

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the teal and pink bars having different lengths, at different window sizes

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

This seems to be a pixel-snapping inconsistency, that seems to occur when we've got a fractional x-position and width.

Here's a more-reduced testcase, with an explicit fractional pixel offset (from margin-left) and a 1px border around both divs, which makes it easier to see when the pink bar "overshoots".

EXPECTED RESULTS:
Both bars should be nicely contained in the lime border.

ACTUAL RESULTS:
The pink one covers up the right edge of the lime border.
(This is what happens in my linux configuration where window.devicePixelRatio is 1 at least. On HiDPI displays with different devicePixelRatio values, the testcase might require a different set of fractional values to show the issue.

Comment 7

[Daniel Holbert [:dholbert]]

I suspect this is a web painting bug. tnikkel, do you know if we have a bug filed on this already?

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 in Firefox on dholbert's linux desktop

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 3

Just to make things slightly more interesting, here's a testcase where the CSS transform actually does do something (shifting content vertically by -10px).

We show the same bug here; the pink bar covers up the lime border at its right edge, despite the lime border being on an element that's sized to fit it, and the pink bar not having any sort of horizontal transform component.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 3

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (testing a grid of 0.1px-increment width and margin combinations)

Here's a testcase that probably shows the issue (the right border edge being covered up) somewhere, even on HiDPI screens.

Comment 12

[Daniel Holbert [:dholbert]]

This is not a regression, or at least not a recent one, for what it's worth. I can reproduce the exact same issue in e.g. Nightly 2016-01-01 (version 46.0a1).

Comment 13

[Timothy Nikkel (:tnikkel)]

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

I suspect this is a web painting bug. tnikkel, do you know if we have a bug filed on this already?

We probably do, but I'm not sure what it is.