Thanks for the report.Able to reproduce the issue on Mac 10.11.3,Win 7 and Ubuntu 14.04 using canary 51.0.2673.0 and its broken in M 50.

Bisect info:
------------
Good :50.0.2628.0 
Bad :50.0.2629.0 
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/e0b6a82cadecbda7e005921c2416fc7afb3542aa..1fee3b4957164505e70df4152fa31a2807fefa74
suspect : https://codereview.chromium.org/1591043002
dgrogan@ : Could you please take a look into this issue, if its related to your change.

Added RB-beta as its working fine on Latest stable 49.0.2623.87 and broken in M 50, please modify if its not appropriate.

Admin stuff:

- This report is due to my change.

- I won't have time to look at it in depth until friday (california time, gmt-7)

- I _suspect_ Gabriel will have to change his layout strategy so I am punting this to ReleaseBlock-Stable.

Real stuff:

My change should only affect boxes that have a percent height and are inside table cells that have auto height. At first glance I don't see how your content fits this, but if you do and could point it out to me that would be helpful. Note that according to css, we fill in gaps in tables (like a missing table section and table cell) with anonymous boxes. If you do figure out how your content fits this pattern, you could change the auto height to height: 100% and I suspect your layout would work with no further modifications. This is probably going to be the outcome of this bug. (It has been the outcome of the similar regression reports I've received as fallout from my change.)

> Does this work in other browsers? Yes 
Well, kind of. it looks like FF and IE11 agree on a behavior[1] that is different from Blink/WebKit. And presto had a different behavior altogether, FWIW. I haven't looked at Edge yet. Gabriel, if you could do that, it would be helpful.

[1] https://dev.windows.com/en-us/microsoft-edge/tools/screenshots/#http://jsfiddle.net/gabrielmaldi/q258g40y/embedded/result/

> Chrome 51 seems to require a specific height to be set on .my-component_top-content (e.g. height: 300px;). This shouldn't be necessary since it should fill the remaining space of the container (this works fine in Chrome 49).

This is too conclusory to be helpful. If you could show which parts of the CSS spec dictate this behavior and exactly how chrome deviates, that would be awesome.

This seems to be the root cause of this issue: https://jira.atlassian.com/browse/CONF-41035

Hi, dgro, thank you for your feedback.

I tested on Edge (25) and it doesn't work the way it does in Chrome 49; it displays the  entire green content without scroll and below that the orange content, the scroll is placed on the body of the page.

I agree that my statement was conclusory; I thought that Chrome's (49) behavior was correct and that's why I submitted this issue. I don't have enough expertise in CSS to conclude that this behavior is correct, or to point you to a relevant section in the spec. However, I have seen a couple of sites break due to this (and apparently the last comment is pointing to another one), and that also led me to believe that this was a regression.

I tried many things to try to make my example work (both changing CSS and the layout) but couldn't get the result I want (which is what Chrome 49 does). If it's not too much trouble, how would you achieve this? (what I want is that the bottom box takes as much height as it needs for its content, and that the top box fills the remaining height of the container, generating scroll for its content if necessary).

Thanks!

I am on the same page as gabrielm, I do not know what behaviour is correct in the technical sense.  However, the behaviour in Chrome 49 is the same behaviour in most every other browser. Changing it now will cause a lot of websites to break and this will be very annoying for Chrome users.

> However, the behaviour in Chrome 49 is the same behaviour in most every other browser.

The chrome 49 behavior doesn't match Firefox. The chrome 50 behavior does. So sites that break in chrome 50 are also broken in Firefox.

From comment 4:
> I tried many things to try to make my example work (both changing CSS and the layout) but couldn't get the result I want (which is what Chrome 49 does). If it's not too much trouble, how would you achieve this? (what I want is that the bottom box takes as much height as it needs for its content, and that the top box fills the remaining height of the container, generating scroll for its content if necessary).

I will probably be unable to help here. Were you able to get it working in any other browser? Are you designing content that will only be consumed in chrome?

@dgrogan I'm using this design for "native web apps" (HTML embedded in WebView) for both Android and iOS. My design works fine in Chrome and Safari (which is more or less what each platform's WebView uses for rendering).

When this change makes it to the Android System WebView (https://play.google.com/store/apps/details?id=com.google.android.webview) many of my apps will break.

This problem breaks my web site. :(

I have downloaded the latest stable version of Firefox (v45).
I browse https://jsfiddle.net/gabrielmaldi/q258g40y/ and I can see and scroll the green content.
Seems that the behaviour of Chrome v50/51 does not match Firefox v45.

@dgrogan Can you treat this as defect and fix it? or which version of firefox are you refering to?

Thanks~

@cyruxwong, firefox 44 and 48 behave the same: you see the green content, and there is a scrollbar on the frame, but no scrollbar on the green content itself.

If you want to see chrome 50 match Firefox then remove the "float: left" rule in that jsfiddle. There seems to be a mismatch between how FF and Chrome treat elements that specify both "float: left" and "display: table-row". FF makes table-row win and chrome makes float win.

As for fixing your site, check out what I said in c2 (edited):
My change should only affect boxes that have a percent height and are inside table cells that have auto height. Change the table cell to be height: 100% instead of auto and everything should work fine.

E.g. my fork of gabrielmaldi's fiddle: https://jsfiddle.net/dgrogan/1w3hmvph/

(Gabriel, could you verify that it works as you expect?)

@dgrogan your solution rocks! It works fine in Chrome 49, Chrome 50, and Safari 9. Thanks a lot!!

Having found a layout that fits my scenario, and given the fact that I can't state that this is a regression as per de CSS spec, and that Firefox behaves the same way, my stance on this issue is that it should be closed.

We should, however, expect some websites breaking due to this; hopefully devs will find their way to this issue and dgrogan's layout.

Thanks again!

This behavior is intentional, closing as WontFix.