Open Bug 2011819 Opened 8 months ago Updated 5 months ago

www.ogcrush.ogcrush.com - Multiple page components are not displayed on the page

Categories

(Web Compatibility :: Interventions, defect, P2)

Desktop
Windows 10

Tracking

(Webcompat Priority:P3, Webcompat Score:2, firefox147 wontfix, firefox148 wontfix, firefox149 wontfix, firefox150 wontfix, firefox151 fixed)

REOPENED
Webcompat Priority P3
Webcompat Score 2
Tracking Status
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:

  1. Access: https://www.ogcrush.ogcrush.com/product-category/accessories/
  2. Scroll down until the end of the page
  3. 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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

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;
}
User Story: (updated)
Webcompat Score: --- → 1
Severity: -- → S2
User Story: (updated)
Webcompat Priority: --- → P2
Webcompat Score: 1 → 6
Priority: -- → P2
Webcompat Score: 6 → 5

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.

Keywords: leave-open
Assignee: nobody → twisniewski
Status: NEW → ASSIGNED
Pushed by twisniewski@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/1976a9449e87 https://hg.mozilla.org/integration/autoland/rev/72d3a8eddde8 add a CSS webcompat intervention for www.ogcrush.ogcrush.com; r=denschub,webcompat-reviewers

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.

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).

(Safari 26.2 matches Chrome on testcase 2, FWIW.)

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.

See Also: → 1578586

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).

Depends on: 2019415

I spun off bug 2019415 as a platform bug here.

User Story: (updated)
Webcompat Priority: P2 → P3
Webcompat Score: 5 → 2

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

Status: ASSIGNED → RESOLVED
Closed: 6 months ago
User Story: (updated)
Resolution: --- → FIXED

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.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Tom, could you remove the intervention and then we can close this?

Flags: needinfo?(twisniewski)

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.

Blocks: 2028133
Component: Site Reports → Interventions
Flags: needinfo?(twisniewski)

The patch landed in nightly and beta is affected.
:twisniewski, is this bug important enough to require an uplift?

For more information, please visit BugBot documentation.

Flags: needinfo?(twisniewski)
Flags: needinfo?(twisniewski)
Pushed by twisniewski@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/1e638b87ce79 https://hg.mozilla.org/integration/autoland/rev/adc571df7e14 only apply our webcompat intervention for ogcrush.com on versions 150 and below; r=webcompat-reviewers,ksenia
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: