www.ogcrush.ogcrush.com - Multiple page components are not displayed on the page
Categories
(Web Compatibility :: Interventions, defect, P2)
Tracking
(Webcompat Priority:P3, Webcompat Score:2, firefox147 wontfix, firefox148 wontfix, firefox149 wontfix, firefox150 wontfix, firefox151 fixed)
People
(Reporter: bfarkas, Assigned: twisniewski)
References
(Blocks 1 open bug, )
Details
(4 keywords, Whiteboard: [webcompat-source:web-bugs])
User Story
user-impact-score:20 platform:windows,mac,linux,android impact:site-broken configuration:general affects:all branch:release diagnosis-team:layout
Attachments
(6 files)
Environment:
Operating system: Windows 10
Firefox version: Firefox Nightly 149.0a1 (2026-01-21)
Steps to reproduce:
- Access: https://www.ogcrush.ogcrush.com/product-category/accessories/
- Scroll down until the end of the page
- Observe the UI
Expected Behavior:
The components of the page are loaded accordingly
Actual Behavior:
Multiple page components are missing
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/203155
| Reporter | ||
Updated•8 months ago
|
| Reporter | ||
Comment 1•8 months ago
|
||
Comment 2•8 months ago
|
||
Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.
Comment 3•8 months ago
|
||
Removing height: 100%; from the following css (https://www.ogcrush.ogcrush.com/wp-content/themes/savoy/assets/css/third-party/slick.min.css?ver=1.5.5) will resolve the issue.
.slick-slide {
display: none;
float: left;
height: 100%;
min-height: 1px;
}
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
| Assignee | ||
Comment 4•7 months ago
|
||
Thanks for the hint, Alice! This CSS seems to do the trick more precisely:
.slick-slide {
height: fit-content;
}
I'll use that in an intervention.
| Assignee | ||
Comment 5•7 months ago
|
||
Updated•7 months ago
|
| Assignee | ||
Updated•7 months ago
|
Comment 8•7 months ago
|
||
| bugherder | ||
Comment 9•7 months ago
|
||
Here's a somewhat reduced testcase. I've added a blue border around the .slick-track element.
In Firefox, that blue border encompasses a bunch of blank white space, and you can't actually scroll to reach the bottom edge of the border.
In Chrome, the blue border doesn't encompass any blank white space, and you can scroll to reach the bottom edge.
Comment 10•7 months ago
|
||
This seems to be a quirks-mode thing. If I add <!DOCTYPE html> to the start of the testcase, then Firefox changes behavior to match Chrome (and Chrome does not change its behavior).
Comment 11•7 months ago
|
||
Comment 12•7 months ago
|
||
Comment 13•7 months ago
|
||
(Safari 26.2 matches Chrome on testcase 2, FWIW.)
Comment 14•7 months ago
|
||
The issue here seems like a form of bug 1578586, though that bug is fixed. So there must've been a case there that was not properly handled, or something along those lines.
Comment 15•7 months ago
|
||
It looks like Chrome used to apply this same quirk in this situation too, but it's been quite a while since they stopped doing so.
Chrome 73 and earlier match current Firefox (rendering testcase 2 with red visible).
Chrome 74 and later match current Chrome (rendering testcase 2 with no red visible, i.e. the blue bordered area is 0-height).
Comment 16•7 months ago
|
||
I spun off bug 2019415 as a platform bug here.
Updated•7 months ago
|
Comment 17•6 months ago
|
||
The platform bug has now been fixed (and its fix is slated to ride the trains -- not behind a pref or anything like that).
Firefox 149.0 (64-bit) (without the fix) still gives ACTUAL RESULTS (looks like left half of comment 1).
Nightly 151.0a1 (2026-03-30) (with the fix) gives EXPECTED RESULTS (looks like right half of comment 1).
--> FIXED in v151
Comment 18•6 months ago
|
||
Ah hold on, I should reopen this since we've still got an intervention in-tree, and probably we'll want to remove that before closing.
Comment 19•6 months ago
|
||
Tom, could you remove the intervention and then we can close this?
| Assignee | ||
Comment 20•6 months ago
|
||
Thanks for the heads-up. I'll make this intervention only activate on version 150 and older, and we can remove it and close this bug once it's no longer helpful on ESR builds.
| Assignee | ||
Comment 21•6 months ago
|
||
Comment 22•6 months ago
|
||
The patch landed in nightly and beta is affected.
:twisniewski, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
- If no, please set
status-firefox150towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•6 months ago
|
Comment 23•5 months ago
|
||
Comment 24•5 months ago
|
||
| bugherder | ||
Description
•