Environment: ---------------------- Samsung GT-N5110 Android 4.1.2 Firefox 46.0b8 Nightly 48.0a1(2016-04-12) Go to the detail page of the product on m.jd.com e.g. http://item.m.jd.com/product/1570254.html?t=1460096907823&jd_pop=0fda687a-6194-4105-af90-b49c03b8e3f2&abt=2&utm_source=m.jd.com&utm_medium=tuiguang&utm_campaign=t_52006_258524_1986&utm_term=0fda687a61944105af90b49c03b8e3f2 Expected results: ---------------------------- The pictures of the product should be like the one when layout.css.prefixes.webkit is false. Pls refer to the attachment.

Here's the inline styles applied on the parent li.J_ping in Firefox w/ layout.css.prefixes.webkit: true element {transition: all 0ms ease 0s;height: 800px;width: 320px;transform: translate3d(0px, 0px, 0px);} And in Chrome: element.style {transition: all 0ms ease;height: 320px;width: 320px;transform: translate3d(0px, 0px, 0px);} Will start poking around for why the height is so different.

http://st.360buyimg.com/item/js/5.0/ware/slide.js?v=jd2016040717025 height is coming from `k.oBox.style.height = d[0].offsetHeight + "px"`, where d[0] is the img's parent li. The natural height of the image *is* 800px. Ah. http://st.360buyimg.com/item/css/5.0/ware/product.detail.all.css?v=jd2016040717025 .slide ul > li { width: 320px; height: 320px; visibility: visible; position: relative; background-color: #fff; float: left; display: -webkit-box; -webkit-box-pack: center; -webkit-box-align: center; } Removing display:-webkit-box makes the image jump back to a reasonable size. Daniel, is this fixed by some of the work you're doing with -webkit-box? (I'm guessing dupe of Bug 1257688?)

(Oh wait, I didn't realize Bug 1257688 had landed -- this is still busted in Nightly, so not that one)

This is not fixed by anything I'm actively working on. I'll take a look, though. There are known issues where modern flexbox is a bit counterintuitive w.r.t. images & aspect ratios (some of which are bugs, and some of which are correct per spec). We might be running into one of those here.

OK, I believe this is effectively a form of bug 1030952. (It's a bug in our modern flexbox implementation, which we need to fix both for correct modern-flexbox behavior as well as for correct -webkit-box emulation.) Marking dependency.

Here's a reduced testcase for this bug. (using a <canvas> instead of an <img>, as something simple which I can give large intrinsic size & aspect-ratio) In Chrome, the "max-width" clamps the width of the canvas *as well as* its height. In Firefox, it does *not* successfully clamp its height, and the canvas gets stretched to its full native height despite having its width clamped. (which means we're skewing away from the aspect ratio)

This should be FIXED in the next Nightly by bug 1030952 (which was merged to mozilla-central today). I tested in a local build, and I verified that the image in comment 0's link is no longer warped. (This is kind of a dupe of bug 1030952, but it's a little more complicated than that since it's dependent on webkit prefix support, which makes it a regression from a user's perspective, even though bug 1030952 isn't a regression. So I'll just mark this as FIXED with a dependency on bug 1030952, instead of duping.)

(In reply to Daniel Holbert [:dholbert] from comment #7) > I tested in a local build, and I verified that the > image in comment 0's link is no longer warped. I've tested an actual Nightly with the fix now, too -- latest Nightly, version 49.0a1 (2016-05-02). It's fixed there.

Yep, confirmed fixed on today's Nightly here as well.