1335265 - Flex container doesn't grow (doesn't account) for scrollbar

Status: RESOLVED DUPLICATE of bug 764076

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[Erfan]

Attachment: firefox-bug.png

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.

Comment 1

[Erfan]

Attachment: chrome-nobug.png

Comment 2

[Daniel Holbert [:dholbert]]

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.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

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.)

Comment 4

[Robert Utasi [:hunboy]]

Attachment: absolute, inline-block, max-content testcase

I can repro in several ways this issue on the trunk under windows10.

Comment 5

[ilya.streltsin]

Isn't there any workaround for this? E.g. exotic display values, -moz-prefixed "magic" or something?

Comment 6

[Daniel Holbert [:dholbert]]

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.

Comment 7

[Daniel Holbert [:dholbert]]

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).

Comment 9

[Daniel Holbert [:dholbert]]

It looks like bug 764076 is a much-earlier report of the same issue, so I'm going to dupe this over there & adjust its title for clarity.

Comment 10

[Daniel Holbert [:dholbert]]

(I'll restore the original bug-title here, too, since I've now put the more general bug title [covering the overall issue] on the dupe target bug, and it's weird to have 2 bugs with the same title. )