Bug 37355 - overflow auto is broken on nested flex boxes
Summary: overflow auto is broken on nested flex boxes
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Keywords: HasReduction
Depends on:
Reported: 2010-04-09 13:31 PDT by Erik Arvidsson
Modified: 2010-11-04 13:54 PDT (History)
7 users (show)

See Also:

Test case (3.30 KB, text/html)
2010-04-09 13:31 PDT, Erik Arvidsson
no flags Details
Patch v1 (9.95 KB, patch)
2010-04-27 08:08 PDT, Shinichiro Hamaji
hyatt: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Arvidsson 2010-04-09 13:31:37 PDT
Created attachment 52984 [details]
Test case

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.
Comment 1 Shinichiro Hamaji 2010-04-26 01:43:13 PDT
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.
Comment 2 Shinichiro Hamaji 2010-04-26 05:26:34 PDT
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.
Comment 3 Erik Arvidsson 2010-04-26 09:31:36 PDT
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?
Comment 4 Shinichiro Hamaji 2010-04-26 10:19:11 PDT
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!
Comment 5 Shinichiro Hamaji 2010-04-26 10:39:49 PDT
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.
Comment 6 Shinichiro Hamaji 2010-04-27 08:08:32 PDT
Created attachment 54417 [details]
Patch v1
Comment 7 Adam Barth 2010-06-20 10:52:53 PDT
Do we need hyatt to review this change, or is there someone else who understands the flexbox layout code?
Comment 8 Nikolas Zimmermann 2010-07-30 22:34:38 PDT
Dan may know the code as well. Hopefully either Dave or Dan can comment here, this is pending since ags.
Comment 9 Nikolas Zimmermann 2010-10-31 14:48:52 PDT
David, Dan can any of you comment? This patch is lurking for 6 (!) months now...
Comment 10 Dave Hyatt 2010-11-04 13:54:59 PDT
Comment on attachment 54417 [details]
Patch v1

Doesn't seem right to assume flexing when you relayout the child.  Patch confuses me.