1973437 - boratool.com - Image gallery layout is broken

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Calin Tanase]

Environment:
Operating system: Linux/Windows 10
Firefox version: Firefox 139.0/141

Steps to reproduce:

1. Go to https://boratool.com/ngx-saw-plate.html
2. Wait for the image gallery to load. (refresh the page it appears to be stuck loading)
3. Click on the gallery arrows to navigate it.

Expected Behavior:
The images are displayed correctly.

Actual Behavior:
The gallery height is bigger and it shows halves of 2 different images.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/163064

Comment 1

[Calin Tanase]

Attachment: image.png

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Attachment: Standalone test case

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Attachment: More reduced test case

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Attachment: More reduced test case

If I add a new line before the first div with class="slick-item slick-slide slick-cloned" the rendering looks much more similar between Chrome and Firefox

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Attachment: More reduced test case

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Attachment: Reduced test case

It looks like this is caused by a subtle difference in sizing with zoom: 85%; between slick-track and it's children

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 3 (like 2 but with a background instead of a border on the container)

(er, this updated testcase makes the math slightly easier to reason about in frame tree dumps, by removing the influence of borders)

Comment 9

[Daniel Holbert [:dholbert]]

Using my reduced testcase 3, looking at frame-tree-dumps:

If I edit the testcase to remove the zoom styling (which avoids the problem), then:

• the container's 570px width maps to 34200 app units (570 * 60 = 34200)
• each child's 190px width maps to 11400 app units (190 * 60 = 11400)
• three children precisely fit in the parent (11400 * 3 = 34200)

But with the included zoom: 85% styling, then:

• the container's 570px width maps to 28856 app units, though it should be 29070 if we had perfect arithmetic. (570 * 60 * .85 = 29070)
• each child's 190px width maps to 9619 app units, though it should be 9690 if we had perfect arithmetic. (190 * 60 * .85 = 9690)
• three children do not fit in the parent due to our precision issues. (9619 * 3 = 28857 which is just barely larger than the parent's 28856-app-unit-width.)

We seem to be scaling things down a bit more than we should be, for some reason (and by a bit more than floating-point-error would trigger....)

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 4

Here's a reduced testcase applying various zoom factors to various multiples of 100px. All of the resulting elements should render at precisely 100px wide, but they don't; some are wider (particularly near the top), some are skinnier (revealing some of the red behind them).

Comment 11

[Daniel Holbert [:dholbert]]

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

We seem to be scaling things down a bit more than we should be, for some reason (and by a bit more than floating-point-error would trigger....)

Ah right, that's because we don't represent zoom as floating-point -- we represent it as a 16-bit fixed-point value, with range from 0 to 1023.984375, per https://searchfox.org/mozilla-central/rev/c25dbe453ff9ca10f2c6bdfb873893c515a29826/servo/components/style/values/computed/box.rs#121-129

So that's why:
(a) we're getting values that aren't quite exact (sometimes over/undershooting in testcase 4)
(b) we end up with fixed-point values that happen to convert to "unlucky" floating-point values which scale app-units in a way that produces fractional app-units, which need to be rounded in ways that might cause things to not fit and hence linewrap, as in testcases 1-3 (presumably in the fixed-point-zoom --> float --> nscoord arithmetic that happens here),

Comment 12

[Daniel Holbert [:dholbert]]

I filed bug 1974099 on the fact that our zoom representation is less precise than other browsers here.

Comment 13

[railioaie]

The issue is no longer reproducible

Firefox Nightly 142.0a1 (2025-07-08)
Windows 10

Comment 14

[railioaie]

Verified, the issue is no longer reproducible.

Tested with:

• Browser 141.0- candidate build 1
• Operating system: Windows 10