1923245 - Google store's "compare cameras" page has broken layout at certain window sizes

Status: NEW

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

Description

[Will]

Attachment: nestsitebroken.png

On some webpages (example is https://store.google.com/magazine/compare_cameras?hl=en-GB ) the layout is broken or incorrect at certain window sizes. To repro, go to that webpage and adjust the width of the window until you see it break at certain widths. I cannot repro in Chromium browsers.

I don't think it's a rounding error because I can still repro when laptop display scaling is set to 200% and Firefox + webpage are at default 100%.

Comment 1

[Will]

Attachment: 2nd screenshot of it broken

Comment 2

[Will]

Attachment: nestsitecorrect1.png

here's what it should look like

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:nalexander, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Tomislav Jovanovic :zombie]

Moving this as WebCompat folks would know what the next step wold be in investigating this.

(In reply to Will from comment #0)

On some webpages (example is https://store.google.com/magazine/compare_cameras?hl=en-GB ) the layout is broken or incorrect at certain window sizes. To repro, go to that webpage and adjust the width of the window until you see it break at certain widths. I cannot repro in Chromium browsers.

In the mean time, I wasn't able to reproduce this, but given that this page might have changed since you reported it, could you please confirm if it's still happening (and we are seeing different pages in different regions), or provide another example?

I think opening a bug is fine if you find a similar issue on multiple pages, but in general WebCompat folks might prefer a report at https://webcompat.com/.

Comment 5

[Will]

I can still repro in v132. The easiest way to repro is, do not have the window maximized, and adjust the size of the window slowly until you see it look something like the screenshots. I did ask a friend about this and he says he thinks it might be a rounding error.

The reason I filed this bug is because I have seen similar issues in Firefox from time to time and though I don't know if they all have the same cause, I thought it was still best to report it in case it's a valid bug

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:twisniewski, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Daniel Holbert [:dholbert]]

I can reproduce. It's easiest to repro in responsive design mode where you can adjust the size of the window 1px at a time. On my system, viewport widths of 1025px and 1026px are fine, but 1027px triggers the issue. 1028px and 1029px are fine, but 1030px triggers the issue. And so on, with every 3rd pixel-valued size being "bad".

Comment 8

[Daniel Holbert [:dholbert]]

So these particular containers have flex-wrap:wrap; so when the rounding works out such that things don't quite fit, the last flex item wraps to a second line (and then both the first and second lines have their content centered, per justify-content:center).

I'm tracking down the arithmetic in the markup that results in overflow...

Comment 9

[Daniel Holbert [:dholbert]]

So at a viewport width of 1030px (a bad one per comment 7), we have the following sizes for the flex container that's got the images:

• flex container has width of 814.333px
• flex container has column-gap: 24px
• flex items have width: 255.45

So the 3 flex items (and 2 gaps between them) require 3*255.45px + 2*24px = 814.35px, which is about .02px wider than the flex container (almost certainly one nscoord unit, 1/60th of a CSS pixel, the smallest size that we represent internally for layout like this). So they overflow and the last flex item wraps to the next flex line.

Comment 10

[Daniel Holbert [:dholbert]]

The sizes here seem to come from some arithmetic that the site's doing in CSS.

I'm focusing on the <div class=" container "> elements inside of each bento-grid-item custom-element (which are the flex items in the aforementioned flex container, despite "grid-item" in the name). Those divs are what establish the width here. The flex items have this width declaration, defined in a constructable stylesheet:

width: var(--bento-grid-item-width, calc(var(--grid-column-width) * var(--bento-grid-span) + var(--grid-gap) * var(--bento-grid-gap-count)))

and that expression is what results in a width of 255.45px

That arithmetic works out like this:

Firstly, --bento-grid-item-width is undefined, so that gets ignored and we use the next arg -- the calc expression -- as a fallback. So, we're trying to resolve calc(var(--grid-column-width) * var(--bento-grid-span) + var(--grid-gap) * var(--bento-grid-gap-count))

Breaking the components of that expression down...

• --grid-column-width is itself defined as calc( ( ( ( min( (100vw - 0px), 1440px ) ) - 312px ) / 12 ) ). Given that our viewport width is 1030px, I think that works out to (1030px−312px) / 12 = 59.8333px.
• --bento-grid-span is 3.33333 (this is set in the <div class=" container"> element's inline style attribute)
• --grid-gap is 24px
• --bento-grid-gap-count is 2.33333 (this is set in the<div class=" container">` element's inline style attribute)
• So our calc expression for width ends up being:

calc(var(--grid-column-width) * var(--bento-grid-span) + var(--grid-gap) * var(--bento-grid-gap
= 59.8333px * 3.33333 + 24px * 2.33333
= 255.4441px (rounded to 4 decimal places)

....which is just barely smaller than the 255.45px that DevTools is giving me in comment 9.

If we used this more precise 255.4441px value in comment 9's arithmetic, we'd barely avoid overflow, because 255.4441 * 3 + 24 * 2 is 814.3323px which is just under the 814.333px of space that the flex container has available.

But we round at some level (in part to align to our 60th-of-a-pixel app units) and get 244.45px which ends up being slightly-larger and we end up with this overflow.

I suspect this isn't possible to avoid without changing our nscoord basis here; the site here just happens to use fine-tuned arithmetic that happens to work out with Chrome's subpixel representation but results in slight rounding error in Firefox's subpixel representation.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Here's a reduced testcase with just the raw numeric values discussed above. This reproduces the same unwanted overflow-and-linewrapping that happens on the actual Google Store page.

Comment 12

[Daniel Holbert [:dholbert]]

At a platform level, this is essentially bug 1719314.

Chrome uses 1/64th of a pixel, which means that for them, .4441 rounded-to-the-nearest-unit happens to be a rounding-down operation (it's 28.4224 64ths of a pixel, which they round down to 28/64 = 0.4375), whereas for us, .4441 rounded-to-the-nearest-app-unit happens to be a rounding-up operation (it's 26.646 60ths of a pixel, which we round up to 27/60 = 0.45

I think we can trivially come up with a testcase where Chrome rounds up and overflows whereas Firefox rounds down; so it's sort of a site bug to depend in such a fine-tuned way on a particular pixel-rounding behavior. Nonetheless, sites will probably continue to accidentally stumble on this, so aligning with Chrome's subpixel representation might be the only way around it.

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (works in Firefox and Chrome)

For reference, this is a variant of the last testcase that I speculatively wrote, with numbers tweaked[1] to attempt to demonstrate the same problem in Chrome (assuming they have 1/64th-of-a-pixel resolution), but this actually works there - I'm not entirely sure why/how. Maybe they intentionally round down at some level in an attempt to avoid this sort of issue?

[1] in particular, in this testcase, I made the flex items 255.308px, and in a 64-app-units-per-pixel representation, that fractional .308px portion is 19.712 app units (which would round up to 20), vs. in a 60-app-units-per-pixel representation is 18.48 (which would round down to 18). And I sized the container to the precise size that you'd expect if there were no rounding, which is 255.308×3+24×2 = 813.924px. In a 64-units-per-pixel representation, assuming rounding as just discussed, I'd expect the items+gaps to occupy 3*(255+20/64)+2*24 which is 813.9375 = 813 and 60/64ths of a pixel; whereas the container itself is specified as 813.924px wide which rounds down to 813 and 59/64ths of a pixel. So I'd expect to overflow by 1/64th of a pixel, but Chrome doesn't for whatever reason.

Comment 14

[Daniel Holbert [:dholbert]]

In any case, testcase 2 will be useful as a "breaktest" if/when we fix bug 1719314. I suspect it might break (i.e. start linewrapping) in Firefox when we change our representation; and I don't know exactly how Chrome avoids that problem with their 64-units-per-pixel representation right now.

Comment 15

[Will]

Thank you! I've run into other webpages that have very similar issues. If I remember them or come across more I'll bookmark them and test if 1719314 gets fixed