Open Bug 764076 Opened 12 years ago Updated 10 months ago

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


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

1.9.0 Branch




(Reporter: jachym.tousek, Unassigned)


(Blocks 1 open bug)


(Keywords: parity-chrome, parity-edge)


(7 files)

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.
Attachment #632353 - Attachment mime type: text/plain → text/html
Component: Untriaged → Layout: Block and Inline
Product: Firefox → Core
This bug still exists after all this time.
Regression window:
Last Good:
First Bad:

Regressed by: Bug 405952
Blocks: 405952
Ever confirmed: true
OS: Windows 7 → All
Version: 14 Branch → 1.9.0 Branch
See Also: → 1471895
Too late for a fix in 64. We could still take a patch for 66 or possibly 65.
Summary: Scollbar inside of a div (overflow: auto; white-space: nowrap;) → Scrollbar inside of a div (overflow: auto; white-space: nowrap;)

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?

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?

Flags: needinfo?(xidorn+moz)
Flags: needinfo?(svoisen)
Flags: needinfo?(dholbert)
Priority: -- → P3

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

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.

Flags: needinfo?(xidorn+moz)
Flags: needinfo?(dholbert)

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

Component: Layout: Block and Inline → Layout: Scrolling and Overflow
Hardware: x86_64 → All
Summary: Scrollbar inside of a div (overflow: auto; white-space: nowrap;) → intrinsic width of "overflow:auto" element doesn't grow to accomodate its scrollbar

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

Attachment #632353 - Attachment description: overflow-auto.html → testcase 1 (from reporter)

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


  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
Blocks: 1535195
Blocks: 1548155
See Also: → 1167911

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

This test show how text is partially hidden on right with overflow: auto and not with overflow: hidden:

Attached file Testcase #4

Chrome is still buggy (tested version 88.0.4315.5).

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

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

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

Adding scrollbar-gutter doesn't quite solve the problem, as you can see here:

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

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.

Flags: needinfo?(guilherme)

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

Flags: needinfo?(guilherme)
Severity: normal → S3

I think Blink fixed this in (r397112).
There was also some refinement in (r436414).

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.

Flags: needinfo?(hikezoe.birchill)
Flags: needinfo?(hikezoe.birchill)

S3 seems accurate here.

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:

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:

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

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

The relevant spec is

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.

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

Duplicate of this bug: 1800438
You need to log in before you can comment on or make changes to this bug.