Created attachment 52984 [details]
When overflow is set to auto in a nested flex box the scrollbars are put on the wrong element and scrolling scrolls the wrong element.
In the attached test case. Make the window small enough to make scrollbars appear. Now try scrolling and you'll notice that scrolling is not working as expected.
Let me check if I understand this bug correctly. I think this issue is happening even without nested flex boxes. If I understand correctly, the following test case is failing with the current WebKit.
I believe the inner div should be a square, with a vertical scrollbar. If we change "overflow: auto" to "overflow: scroll", it looks OK.
WebKit: overflow:auto is failing, but scroll, visible, and hidden look OK.
Firefox: it seems Firefox is failing for all overflow values. It does never shrink the inner box.
Better test case for Mac Safari:
I've found Mac Safari's font is smaller than Chrome so overflow doesn't happen with the previous URL.
I'm actually not sure these are the same bugs. The behavior in my test case is that scrollbars show up but scrolling those does not scroll the right *content*. It might be that my test is too confusing to be useful?
I'm guessing if we fix my test case, your test case will be also fixed. But yeah, I'm not sure yet, but let me explain my current understanding.
I think the broken content in your test case happens because the render layer of the inner most element shrinks to match the height of the window (this is the right behavior), but the inner most div element doesn't shrink. As the paint result of the inner most element will be clipped by its layer, the content isn't painted when we scroll. If the inner most div element shrinks, the inner most element will have the scrollbar and the window won't have the scrollbar. Then, if we don't have scrollbar of the browser window, it means we won't see the clipped contents as we cannot scroll the body element. Instead, we will see the scrollbar of the inner most element and we should be able to scroll the texts with this scrollbar properly.
But I might be wrong. I need more investigation. Thanks for your comment!
I'm not sure I could explain well... In summary, I'm guessing my test case can explain the root cause of this issue.
By the way, I'm not 100% sure if my understanding of the right behavior for my test case is correct. The spec (http://dev.w3.org/csswg/css3-flexbox/) says
"Elements within a box may use the ‘overflow’ property to control whether a scrolling mechanism appears when the children of a box overflow. A scrolling mechanism may be displayed when flexible elements are reduced below their minimum intrinsic size when the overflow property is set to auto or scroll. If overflow is hidden, the element will be clipped instead. Note that the initial value is visible, which is typically not the preferred effect in user interfaces."
So, it seems the inner most div element should shrink and have a scrollbar. But it seems Firefox doesn't implement this correctly (this can be fixed in a newer version of Firefox though). As this spec is written by a Firefox guy, this situation is somewhat strange. That's why I wanted to check my understanding and added hyatt into the CC list of this bug. I hope he'll check if http://tinyurl.com/3yeksvv is a right test case when he has time.
Created attachment 54417 [details]
Do we need hyatt to review this change, or is there someone else who understands the flexbox layout code?
Dan may know the code as well. Hopefully either Dave or Dan can comment here, this is pending since ags.
David, Dan can any of you comment? This patch is lurking for 6 (!) months now...
Comment on attachment 54417 [details]
Doesn't seem right to assume flexing when you relayout the child. Patch confuses me.