1966377 - www.nvidia.com - Header content overflows

Status: ASSIGNED

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

Description

[Calin Tanase]

Environment:
Operating system: Android 13
Firefox version: Firefox Mobile [phone]

Steps to reproduce:

1. Go to https://www.nvidia.com/en-eu/
2. Zoom out.
3. Observe the page.

Expected Behavior:
The header and the page content is displayed correctly.

Actual Behavior:
The header overflows, leaving a blank space on the right side of the page content.

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

Comment 1

[Calin Tanase]

Attachment: image.png

Comment 2

[Dennis Schubert [:denschub]]

Reproducible in RDM, seems like some element is too wide. You can zoom/pan, so this isn't super broken.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (reduced)

The header looks different, but it's a downstream symptom of the real problem -- as Dennis noted, some other element is too wide and inflates the scrollable area, and the header is just filling that unexpectedly-wide area.

The too-wide-element is a carousel, I think, which is mostly clipped but does contribute some scrollable overflow.

Here's a reduced testcase that demonstrates this. In Firefox in RDM, the viewport here is horizontally scrollable (indicating that there's some overflow). In Chrome in RDM, the viewport is not horizontally scrollable.

Comment 4

[Daniel Holbert [:dholbert]]

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

Created attachment 9488490 [details]
testcase 1 (reduced)

The header looks different, but it's a downstream symptom of the real problem -- as Dennis noted, some other element is too wide and inflates the scrollable area, and the header is just filling that unexpectedly-wide area.

This^ is happening because of some styles that are wrapped in a @-moz-document url-prefix(){ check (which is basically just if (firefox) { ... } which Firefox recognizes and enters, while other browsers do not. Quoting the attached testcase: they have these styles:

@-moz-document url-prefix(){
.nv-carousel-home .cmp-carousel__slides.fixed-width{
scrollbar-color:#76b900 #ccc;
scrollbar-width:none;
}
.nv-carousel-home .cmp-carousel[data-cmp-scroll-width] .cmp-carousel__content:after{
border-bottom:1px solid #ccc;
bottom:0;
content:"";
left:0;
margin:auto;
position:absolute;
right:0;
width:calc(100% - var(--carousel-fixed-width-spacer)*2);
}
}

The most problematic bit of those Firefox-only styles is the last line, which ends up resolving to a very large width -- large enough to run quite far offscreen. It looks like it'll be less than 100% (i.e. it'd be something that'd fit on-screen), but in fact --carousel-fixed-width-spacer turns out to be negative here -- it has this value:
--carousel-fixed-width-spacer:calc(50vw - 645px);
...which for a 328px-wide-screen works out to -481px. So the above width expression is subtracting -481px*2 which really means adding 481px*2, i.e. the element ends up being nearly 1000px wider than the screen.

This all seems to be NVIDIA trying to create some sort of browser-specific fake scrollbar-track for their carousel (they use -webkit-scrollbar, -webkit-scrollbar-track, and -webkit-scrollbar-thumb to style the scrollbar on other browsers, which does nothing for us). And their Firefox-specific CSS is unfortunately broken as noted above.

Comment 5

[Daniel Holbert [:dholbert]]

So, summing up:

1. NVIDIA has some legitimately broken CSS here, which is only visible to Firefox.
2. It's only visible to Firefox due to bug 1449753 (the fact that Firefox processes -moz-document styles)
3. The reason NVIDIA is using -moz-document in the first place seems to be their attempt to provide some fallback styling because we don't support their -webkit-scrollbar styles, which is bug 1432935.

Bugs 1449753 and bug 1432935 are both WONTFIX, so it's unlikely we can address this by "just" fixing those bugs.

So I think our likely only solution here is to address (1), i.e. ship a sitepatch and/or do outreach to address their broken CSS.

Comment 6

[Daniel Holbert [:dholbert]]

Here's one suggested sitepatch that fixes the issue for me in RDM (clamping their accidentally-huge width expression from comment 4, which is almost-certainly meant to be something smaller than 100% but in fact works out to be much much bigger on small screens due to --carousel-fixed-width-spacer going negative):

.nv-carousel-home .cmp-carousel[data-cmp-scroll-width] .cmp-carousel__content:after{
	max-width: 100%;
}

Comment 7

[Daniel Holbert [:dholbert]]

The broken styles in question here (that I quoted in comment 4) live in an inline <style> element on https://www.nvidia.com/en-eu/ itself (and also https://www.nvidia.com/en-us/ and probably other variants of that front page).

Some research would be required to decide how broadly to apply the sitepatch-rule that I quoted in comment 6 (i.e. to find out how many pages have this <style> element and a similarly-broken carousel with a way-too-wide ::after element)... But I suspect that sitepatch's selector is specific enough and the max-width is harmless enough to just apply it to *.nvidia.com -- maybe specifically for Android, since that's where this is most likely to be a problem.

Comment 8

[Raul Bucata]

The page is now broken when directly accessed, without doing anything

Tested with:

Browser / Version: Firefox Nightly 141.0a1 (2016094791-🦎141.0a1-20250603213222🦎)
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density)
Operating System: Oppo Find X5 (Android 13) - 1080 x 2400 pixels, 20:9 ratio (~402 ppi density)

Comment 9

[Thomas Wisniewski [:twisniewski]]

The site is loading for me with the original problem, and Dan's suggested CSS fix seems to be working for me. I'll turn it into an intervention. I agree with Dan that it seems safe enough to apply broadly to *.nvidia.com/*, and if not, I'm sure users will help to discover and report any unexpected breakage.

Comment 10

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1966377 - add an Android-only CSS webcompat intervention for nvidia.com to fix their overflowing mobile layout; r?denschub

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0b87653b06c2
https://hg.mozilla.org/mozilla-central/rev/93172dc7bd58
add an Android-only CSS webcompat intervention for nvidia.com to fix their overflowing mobile layout; r=denschub,webcompat-reviewers

Comment 12

[amarc]

https://hg.mozilla.org/mozilla-central/rev/93172dc7bd58

Comment 13

[Raul Bucata]

I can not zoom out using the latest Nightly, same as in Chrome, so no breakages are present. But the attached test case allows zooming out in Firefox, but not in Chrome, using pinch to zoom. Daniel, should we consider this as reproducible?

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to Raul Bucata from comment #13)

But the attached test case allows zooming out in Firefox, but not in Chrome, using pinch to zoom. Daniel, should we consider this as reproducible?

Thanks for asking -- no, we shouldn't consider this reproducible based on that testcase.

The behavior-difference on the testcase is expected, per comment 4. (The testcase uses some CSS that only Firefox understands, which triggers an expected behavior-difference between us and Chrome.)

The sitepatch that we landed is intended to mitigate that so that the actual live site doesn't hit that same behavior-difference.