1258733 - No image displayed when hitting Next button on mashable.com gallery (due to -webkit-box emulation with modern flexbox, & default "flex-shrink:1")

Status: RESOLVED DUPLICATE of bug 1257688

(Core :: CSS Parsing and Computation, defect)

Description

[Ada [:adalucinet]]

[Affected versions]: latest Aurora 47.0a2 and Nightly 48.0a1 (from 2016-03-21), e10s enabled/disabled

[Affected platforms]:
- Mac OS X 10.11.1
- Ubuntu 14.04 32-bit
- Windows 7 64-bit

[Steps to reproduce]:
1. Launch Firefox.
2. Navigate to http://mashable.com/2011/01/16/funny-404-error-pages/#gallery/33-humorous-404-error-pages/50bddbac97b2f830ef00006a
3. Scroll down a little and select 'Open gallery' button.
4. Hit NEXT button.

[Expected result]: The next image(s) is/are properly displayed.

[Actual result]: No image displayed - the gallery area is black.

[Regression range]:
Last good revision: 31edd1840c5f651b5dbf182fdb7f04fe98c88d86
First bad revision: 9fbf850dc78d7197132a298f9ec0270c7de16a13
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=31edd1840c5f651b5dbf182fdb7f04fe98c88d86&tochange=9fbf850dc78d7197132a298f9ec0270c7de16a13

Regressed by 9fbf850dc78d Daniel Holbert — Bug 1213126: Enable support for webkit-prefixed CSS properties & features by default

[Additional notes]:
1. Not reproducible with ‘layout.css.prefixes.webkit’ pref set to false.
2. Note that the spinner is continuously displayed in the title bar.

Comment 1

[Daniel Holbert [:dholbert]]

Thanks -- I can reproduce the bug using latest Nightly.  Mike, perhaps you'd be up for diagnosing?

[Side note: I can't reproduce the continuous-spinner thing mentioned at the end of comment 0 -- but I don't want to sidetrack on that. Let's focus on the "no image displayed" issue here, and then consider a new bug for the spinner as-needed if that issue is still reproducible for anyone once this is fixed.]

Comment 2

[Mike Taylor [:miketaylr]]

Yep, looking into this. I need to break for some late meetings (will pick it up in the morning again), but in the following line:
(from http://rack.0.mshcdn.com/assets/app-badb412ba0dd84773be30b2f483ddab6.js)

t.style[d.transform] = 'WebkitTransform' !== d.transform || h ? a.toString()  : a.toString(!0),

h is false with layout.css.prefixes.webkit=false and true with layout.css.prefixes.webkit=true.

So maybe the transform value is being serialized in a weird way in the "true" path? TO BE CONTINUED...

Comment 3

[Mike Taylor [:miketaylr]]

(to be more clear, d.transform is always "transform" in both cases, so the 'WebKitTransform' comparison is irrelevant)

Comment 4

[Mike Taylor [:miketaylr]]

Oh. h is `h = navigator.userAgent.toLowerCase().indexOf("chrome") > -1;` And it's not the cause of this bug (it just picks a translate or trannslate3d function for the transform).

Comment 5

[Mike Taylor [:miketaylr]]

I was on the wrong track, looking for slidy/transformy things given other related bugs. The real issue here is related to our -webkit-box emulation/aliasing:

http://rack.0.mshcdn.com/assets/posts-967264d5db8397041aa35517a9915db6.css
.mash-lightbox section.gallery.interactive .slide-container {
  display: -moz-box;
  -moz-box-align: center;
  display: -webkit-box;
  -webkit-box-align: center;
  bottom: 25% !important;
}

removing display: -webkit-box here fixes the problem (the slides appear).

Daniel, I'll defer to your knowledge here of what's actually going on.

Comment 6

[Mike Taylor [:miketaylr]]

(It maybe be that patches from Bug 1236400 fixes this, I've only kinda skimmed that issue).

Comment 7

[Daniel Holbert [:dholbert]]

Thanks, Mike!  I probably should have poked at this a bit more up-front -- sorry for not doing so, and thanks for diagnosing! (I'm used to these "content completely missing" bugs being caused by something more JS/DOM-flavored.)

If I add "flex-shrink:0" to the first child of the element in comment 5 -- <div class="slides transitional"> -- the bug goes away.

So, this is the same as bug 1238580 & bug 1256664 -- we just need to suppress the modern-flexbox "flex-shrink:1" default, inside of a webkit-box.

Comment 8

[Daniel Holbert [:dholbert]]

This was broken in yesterday's nightly, and it's fixed in today's nightly (48.0a1 2016-04-06).

 --> Duping to bug 1257688, which fixed it.  (That bug's "part 5" patch addressed the issue described in comment 7 here, by making flex items *not* shrinkable by default, inside of a -webkit-box.)