764076 - intrinsic width of "overflow:auto" element doesn't grow to accomodate its scrollbar

Status: NEW

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

Description

[Jáchym Toušek]

Attachment: testcase 1 (from reporter)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0
Build ID: 20120605113340

Steps to reproduce:

See the attached html file for the actual bug. I've tried to remove everything not bug-related.

The same bug appears to be in Google Chrome. IE8+ and Opera are OK.

I don't know of any work-around yet other then adding some padding-right. Which I of course can't do because of other browsers with correct behaviour. I you do know how to fix this please share in the comment. It would really help me out.


Actual results:

In a bit special case the vertical scollbar appears inside of a div instead of outside.


Expected results:

The test case should be the same with both overflow auto and scroll. The scrollbar should be outside.

Comment 1

[Matt Cosentino]

This bug still exists after all this time.

Comment 2

[Alice0775 White]

Regression window:
Last Good:
http://archive.mozilla.org/pub/firefox/nightly/2008/02/2008-02-28-06-trunk/
First Bad:
http://archive.mozilla.org/pub/firefox/nightly/2008/02/2008-02-29-06-trunk/

Regressed by: Bug 405952

Comment 4

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

Too late for a fix in 64. We could still take a patch for 66 or possibly 65.

Comment 5

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

Happy to take a patch in nightly 67, or potentially, in beta 66 for this.
I'm removing the regression tag from this bug since it's been around for 10 years.

Sean, can you give this a priority, or find someone to investigate?
Is is something where we aren't behaving according to spec?

Comment 6

[Sean Voisen (:svoisen)]

This looks to work as the reporter expects in Chrome now.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

dholbert (or maybe xidorn?): Do you know what the correct behavior is here?

Comment 7

[Daniel Holbert [:dholbert]]

This is the same issue described in bug 1335265. Basically, we don't reserve space for the scrollbar when measuring the intrinsic size of the element currently (because 'overflow:auto' means we might not need a scrollbar).

I'm not sure this is covered in any spec -- CSS 2.1 just says that overflow:auto behavior "is user agent-dependent, but should cause a scrolling mechanism to be provided for overflowing boxes."
https://www.w3.org/TR/CSS22/visufx.html#overflow

But Chrome's behavior is definitely more in line with user expectations. (Though it does result in kind-of-unusual behavior where e.g. changes in descendant heights can influence the container's intrinsic width, by adding/removing a scrollbar.)

So, I think this is a valid bug. I'll adjust the summary and dupe newer bug 1335265 over to this one.

Comment 9

[Daniel Holbert [:dholbert]]

(I'm also not sure why we're bothering setting status flags for each Firefox release. Let's just clear those.)

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced/clearer)

Here's my testcase from bug 1335265, which is a bit more reduced / clear.

Comment 11

[Mats Palmgren (inactive)]

Attachment: Testcase #3 (demonstrates bug in Chrome)

Whatever it is that Chrome is doing - it's unsound.

STR

1. load this testcase in Chrome
2. open devtools
3. select one of the elements that has class="tall"
4. in the Styles tab: toggle the checkbox on the "height" declaration in the ".tall" rule

Comment 12

[Mats Palmgren (inactive)]

Attachment: Screenshots of Chrome with the STR in comment 11

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren (:mats) from comment #11)

Created attachment 9046279 [details]
Testcase #3 (demonstrates bug in Chrome)

Whatever it is that Chrome is doing - it's unsound.

FWIW, Chrome seems to have fixed this issue. In Chrome 83.0.4093.3 (Official Build) dev (64-bit), if I perform your STR for this testcase, I see the scrollbar disappear/reappear, and the red border continues to tightly-wrap the content on top as well as on the bottom. (There's no dead space like the space shown in the top right of your screenshot, attachment 9046280 [details], and the scrollbar doesn't stomp on the border like in the left half of your screenshot.)

Comment 18

[Clément]

This test show how text is partially hidden on right with overflow: auto and not with overflow: hidden: https://codepen.io/yukulele/pen/qVzJeB

Comment 21

[Mats Palmgren (inactive)]

Attachment: Testcase #4

Chrome is still buggy (tested version 88.0.4315.5).

Comment 22

[Mats Palmgren (inactive)]

So it appears Chrome have some kind of heuristic when calculating intrinsic sizes to predict if a vertical scrollbar will be needed or not... Does anyone know what they are doing? (I'm assuming it's not a full reflow since that would kill performance.)

Comment 24

[Daniel Holbert [:dholbert]]

Note that bug 1715112 will make things a little better here, in that we'll have a workaround that we can offer.

For elements that are affected by this bug, scrollbar-gutter: stable should address the issue (with the side effect of making the element slightly larger -- reserving space for scrollbars even when it doesn't have any scrollbars showing, and making it precisely the correct size when there are scrollbars showing).

Comment 26

[Ting-Yu Lin [:TYLin] (UTC-8)]

Attachment: Testcase 5 (Testcase 2 + scrollbar-gutter:stable)

With Bug 1748574 fixed, the workaround in comment 24 is now possible. See the attached Testcase 5.

Comment 28

[Guilherme Lopes]

Attachment: Container with and without scrollbar-gutter

Adding scrollbar-gutter doesn't quite solve the problem, as you can see here: https://plnkr.co/edit/8guCvbmbdCarc5dV?preview

If the container that needed a scrollbar is resized (in my application it is resizable), then it will be uneven.

Comment 29

[Daniel Holbert [:dholbert]]

Would you mind filing that as a separate bug? I'm not sure I fully understand the issue you're reporting (I do see that the two scrollers have different widths but I'm not sure it sounds like you're talking about a different issue than that). It'd be good to have that discussion on a dedicated bug rather than as a side-discussion on this bug, especially if it happens to indicate a defect in our scrollbar-gutter implementation that needs addressing.

Comment 30

[Guilherme Lopes]

I filed a separate issue but it was closed as a duplicate of this one. See the comment 27 - Issue 1760737

Comment 31

[Oriol Brufau [:Oriol]]

I think Blink fixed this in https://codereview.chromium.org/1980103002 (r397112).
There was also some refinement in https://codereview.chromium.org/2553833002 (r436414).

Comment 32

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 11 duplicates.
:hiro, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 33

[Daniel Holbert [:dholbert]]

S3 seems accurate here.

Comment 34

[Jez]

I seem to have filed a dupe of this one with bug #1800438 and this one rings a bell so I'm not sure I haven't read this all before... but anyway, a couple of test cases with and without soft breaks:

https://game-point.net/misc/stickyMaskOverScroll/index6.htm
https://game-point.net/misc/stickyMaskOverScroll/index7.htm

IMO Blink's behaviour here makes more sense. If content would not break with no scrollbar, adding a scrollbar should still not make the content break or overflow when there's width to expand the containing box. The CSS spec looks to me like it does specify this behaviour with something like the absolute positioning model as the content should be given fit-content size:

https://w3c.github.io/csswg-drafts/css-position/#abspos-auto-size

https://www.w3.org/TR/css-sizing-3/#fit-content-size

"When sizing under a min-content constraint, equal to the min-content size. Otherwise, equal to the max-content size in that axis."

max-content-size:
"The box’s “ideal” size in the inline axis. Usually the narrowest inline size it could take while fitting around its contents if none of the soft wrap opportunities within the box were taken"

Wrapping text is taking a soft wrap opportunity, so not in line with the spec.

Comment 35

[Oriol Brufau [:Oriol]]

The relevant spec is https://drafts.csswg.org/css-overflow-3/#scrollbar-layout

When the box is intrinsically sized, this reserved space is added to the size of its contents.
UAs must start with the assumption that no scrollbars are needed, and recalculate sizes if it turns out they are.

Comment 36

[Jez]

Yep, that would seem to make the spec definitive in saying that Chrome's behaviour is correct here.