User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36 Steps to reproduce: Applying a flex-shrink property to a <video> tag (containing webRTC/getUserMedia video) inside of a parent flex container. Actual results: The video won't shrink down as its container gets smaller. Expected results: The video should scale down like it does in webkit. It might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=972595

It should work if you also specify "min-width:0" on the <video>, along with giving it a "flex-shrink". (Could you give that a try and confirm whether it works?) Background: The flexbox spec changed last year to give flex items a new minimum width [below which they won't shrink], via the default "min-width:auto". This prevents them from shrinking below their min-content width, which in the case of the video is its intrinsic width. If you want to override that behavior, you have to explicitly give the flex item "min-width:0". Note that Firefox is the only browser to have implemented this feature in a release yet (though IE has it implemented in their prerelease version, I'm told). Spec text on this: http://dev.w3.org/csswg/css-flexbox/#min-size-auto Tracking bug for other websites that have been bitten by this feature: bug 1043520

It will grow in either direction no problem. It will shrink vertically no problem. But Even when pinning down the min-width and flex-shrink properties, that video wont scale down in this context: video,#localVideo,#remoteVideo { flex-grow: 1; flex-shrink: 1; min-width: 0; min-height: 0; }

By scale down, I mean the width wont scale down.

Then maybe it's not what I thought. Could you attach or link to a testcase demonstrating the problem? It's hard to figure out what's going on without a functioning demo of the problem. I tried to construct a simple testcase locally, and I couldn't reproduce. (I used an OGG video -- I doubt this actually requires WebRTC-based video to trigger it -- though if it was, that would be interesting)

Ah! When constructing a testcase demonstrating that I can't reproduce, I think I stumbled upon what you might be hitting. To trigger the bug, I need to specify an explicit "height" on the flex container, it seems. (This combines with the "align-self:stretch" on the video to stretch it vertically, which then forces it to stretch horizontally as well.)

...though min-width:0 still seems to fix the problem, as shown by the third video here (which is nice and small). (note that "flex-shrink" defaults to 1, so it's implicitly got a nonzero flex-shrink.) Tangent: The overflow with the second example in this testcase does still seem a bit odd, when compared to the first example (which derives its height from shrinkwrapping the video's intrinsic height I think). So that might be indicative of a bug. But that's still different from what you're experiencing, if 'min-width:0' doesn't help you. So, "testcase-wanted" is still true here.\

(In reply to Daniel Holbert [:dholbert] from comment #7) > Tangent: The overflow with the second example in this testcase does still > seem a bit odd, when compared to the first example (Following up on this tangent -- actually, the second example's rendering is correct -- it falls out of these facts: (1) if a single-line flex container has a definite cross size (a specified height, in this case), then any flex items with align-self:stretch (the default) are also considered to have a definite cross size. (of the same value). http://dev.w3.org/csswg/css-flexbox-1/#definite-sizes (2) For a flex item with an intrinsic aspect ratio and a definite height (cross size), its min-width:auto ends up resolving to its "transferred size" which is that definite height converted via the aspect ratio. http://dev.w3.org/csswg/css-flexbox-1/#valdef-min-width-min-height-auto So, in the second example of attachment 8562360 [details], the <video> is considered to have a definite height because of my point (1) here, and that height produces a largeish "min-width:auto" value because of my point (2) here. And if you suppress that with min-width:0, then the width is allowed to be smaller.) So as far as I've seen, all is working per-spec here (though Bret's testcase w/ comment 2 styling & a refusing-to-shrink video may show otherwise).

I will close this issue due to lack of response by the reporter and it seems to have been figured out in comments 6-8. If the issue still persists, please feel free to reopen this issue.