1959132 - www.samsung.com - Products are displayed in a single column instead of two

Status: NEW

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

Description

[Raul Bucata]

Environment:
Operating system: Android 15
Firefox version: Firefox Mobile 137.0

Steps to reproduce:

1. Navigate to: https://www.samsung.com/sec/memory-storage/all-memory-storage/?ssd
2. Scroll and observe the products list

Expected Behavior:
The products are displayed in two rows

Actual Behavior:
Products are displayed in a single row

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/152559

Comment 1

[Dennis Schubert [:denschub]]

Seems to be a multi-column flex layout. Resizing the viewport in RDM makes this flicker.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (reduced)

Here's a reduced testcase. Relevant CSS:

/* container: */
  gap: 3.333vw;
/* child: */
  width: calc(50% - 1.666vw);

This is a rounding bug, where this Samsung site is not really itself enough width, though it occasionally works out.

Samsung is styling each flex item with width: calc(50% - 1.666vw), and they have a gap of 3.333vw between each item. So if we place two flex items on a line (which is what the site is going for), they end up occupying this much space:

2 * item-width + gap-width
2 * (50% - 1.666vw) + 3.333vw
(100% - 3.332vw) + 3.333vw
100% + .001vw

In other words, they're explicitly sizing stuff such that they overshoot their available width by 0.001vw and Firefox is accurately considering the elements to not fit and need to be wrapped in that case (taking advantage of flex-wrap: wrap), except in occasional edge cases where the rounding works out just right for the overshooting amount to round down to 0).

In this testcase, Chrome also flickers between the wrapped/not-wrapped layout, at different viewport sizes (though they tend to opt for the two-items-per-line layout more often than we do, presumably due to differences in internal representation of lengths and resulting different rounding behavior).

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reference case 1 (reduced gap to 3.332vw)

Here's a reference case that's identical to the testcase except with the gap reduced ever-so-slightly to 3.332vw so that the math works out instead of overshooting. This reliably produces the intended 2-column layout.

Comment 5

[Daniel Holbert [:dholbert]]

--> Considering this "diagnosed" and "needs-contact/needs-sitepatch", since this a site bug that's fragile in all browsers depending on the viewport size (as demonstrated by testcase 1) and how it interacts with the browser's internal fixed-point subpixel length representation.

(It's possible bug 1719314 would make us work out to be closer to Chrome here, in terms of which sizes might round down and get lucky and not overshoot the available space. Marking that as a dependent bug.)

As a sitepatch/intervention here, we could reduce the specified gap and/or the sizes of the tiles by a bit. It's not enough to just match the idealized mathematical sizing, though - even with a slightly-reduced 3.332vw per my reference case, the site still doesn't reliably lay out in 2 columns, because our fixed-point nscoord representation might still end up rounding-up for the flex item lengths and not-rounding-down enough on the gap size to be enough to compensate.

Changing the gap to 3.3vw for the flex container seems to robustly work, though. Suggested CSS (replacing part of a rule from the site, with the same selector):

@media screen and (max-width: 800px) {
  .mo_ver2.pf-container .pf-prd-cardlist.col-2 .list-product .list {
        gap: 3.3vw;
  }
}