Closed Bug 1142690 Opened 9 years ago Closed 9 years ago

wired.com photo slideshow is blank in Firefox, but works in Chrome and Firefox 33

Categories

(Web Compatibility :: Desktop, defect)

defect
Not set
normal

Tracking

(firefox36 affected, firefox37 affected, firefox38 affected, firefox39 affected, firefox-esr31 unaffected, firefox-esr38 affected)

RESOLVED FIXED
Tracking Status
firefox36 --- affected
firefox37 --- affected
firefox38 --- affected
firefox39 --- affected
firefox-esr31 --- unaffected
firefox-esr38 --- affected

People

(Reporter: cpeterson, Unassigned)

References

()

Details

(Keywords: regression, reproducible, Whiteboard: [suggested fix for site in comment 4])

STR:
1. Load http://www.wired.com/2015/03/github-conquered-google-microsoft-everyone-else/
2. Click any of the photos in this article.

RESULT:
A slideshow lightbox pops up, but it is blank in Firefox 34+. It works in Chrome and Firefox 33 (and current ESR 31). Curiously, the slideshows on other wired.com articles seem to work correctly.

I bisected this regression to Nightly 34 build 2014-07-23:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=63f44b4968c2&tochange=82df3654cd80
Daniel, could this slideshow bug be fallout from your min-width:auto/min-height:auto changes in flexbox bug 984711 or bug 1015474?
Flags: needinfo?(dholbert)
Almost certainly yes. I'll take a look.
Flags: needinfo?(dholbert)
This rule fixes it, FWIW:
  .wired-gallery > * { min-width: 0}
More targeted rule that also fixes it:
 .slick-slider {
   min-width: 0;
 }

.slick-slider is the "track" in which the slideshow plays. It looks like its min-content size is absurdly large, and you have to use "min-width:0" (which disables "min-width:auto") to avoid letting it take on that size.

(Its large min-content size seems to come from its grandchild, which on my system (with this fixed) is:
> <div style="opacity: 1; width: 11442px; transform: translate3d(-1907px, 0px, 0px);" class="slick-track">
Note the huge explicit width -- this element is intentionally supposed to overflow, and the not-overflowing section is controlled using the "transform" property.

If you don't use "min-width:0", then .slick-slider will shrinkwrap this element's size and end up larger than the designers intended.
Component: Layout → Desktop
Product: Core → Tech Evangelism
I reached out to the folks at Wired who took care of (similar) bug 1138482 -- hopefully they can get this CSS added soon.
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [suggested fix for site in comment 4]
Version: unspecified → Trunk
Heard back -- they're hoping to fix this in the next day or so. Hooray!
Closing the loop here -- STR now give expected results. (it's not blank)

And using devtools, I see they've added the style rule that I suggested as a fix in comment 4 -- quoting their (giant single-line) CSS file:
> .slick-slider{min-width:0}
http://www.wired.com/wp-content/themes/Phoenix/assets/css/style.css?ver=1444077028
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.