Closed Bug 1335265 Opened 3 years ago Closed 8 months ago
Flex container doesn't grow (doesn't account) for scrollbar
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2984.0 Safari/537.36 Steps to reproduce: The code can be found in this codepen (https://codepen.io/anon/pen/JEMyPm) Actual results: The scrollbar in the example makes the content overflow in x direction as well because the scrollbar isn't accounted when calculating in content width ('flex: 0 0 auto' should be the width of content) Expected results: The scrollbar should be counted as part of the content so the container grows when you have overflow in y direction.
Thanks for the report! This isn't actually a flex-specific bug -- it happens with any intrinsically-sized overflow:auto element. (And your testcase just happens to be using flexbox to trigger intrinsic sizing.) I'll attach a simpler testcase that uses "float" to trigger the same problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Flex container doesn't grow (doesn't account) for scrollbar → intrinsic width of "overflow:auto" element doesn't grow to accomodate its scrollbar
Here's a reduced testcase. Both of the scrollable EXPECTED RESULTS: - Both of the scrollable areas should size to fit their content, horizontally (including the scrollbar that they end up needing). - In particular, the first one's "CanYouReadMe" text should be fully visible, and shouldn't have a horizontal scrollbar. - And the second one's text should not wrap. (because the element is intrinsically sized to accommodate that text's preferred width) ACTUAL RESULTS: - The vertical scrollbar steals some of the horizontal space. So in the first scrollable area, the final "e" gets stomped on and there's a horizontal scrollbar. And in the second scrollable area, the text is forced to wrap. Chrome 57 gives EXPECTED RESULTS. Firefox 54 gives ACTUAL RESULTS. (At least on Linux. We might produce nice output on Android/Mac, since I think there we have overlay scrollbars that don't take up space.)
I can repro in several ways this issue on the trunk under windows10.
Isn't there any workaround for this? E.g. exotic display values, -moz-prefixed "magic" or something?
I'm not aware of any workaround, no. Also, for what it's worth: Edge 17 agrees with Chrome's rendering here, whereas Safari 12 (on Mojave) agrees with Firefox's rendering.
Component: CSS Parsing and Computation → Layout: Scrolling and Overflow
OS: Unspecified → All
Hardware: Unspecified → All
Version: 51 Branch → Trunk
I guess there is one kinda-workaround: you can use "overflow-y: scroll" on the scrollframe, rather than "overflow:auto". That gives the browser up-front instructions to set aside some space for the vertical scrollbar. (Though that might be unwanted in some scenarios if you're expecting there not to be vertical overflow most of the time.) Without that instruction, Firefox (and I guess Safari) can't tell whether it'll need the vertical scrollbar until *after* it's done layout to compute heights. And that happens *after* we've already already resolved intrinsic sizes like the widths of these scrollframes (because we need to resolve those widths, in order to do line-wrapping etc. to compute the heights of their contents).
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 764076
Summary: intrinsic width of "overflow:auto" element doesn't grow to accomodate its scrollbar → Flex container doesn't grow (doesn't account) for scrollbar
You need to log in before you can comment on or make changes to this bug.