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




7 years ago
4 months ago


(Reporter: jachym.tousek, Unassigned)


(Blocks 2 bugs, {parity-chrome, parity-edge})

1.9.0 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(4 attachments)

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)
Duplicate of this bug: 1335265

(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
Duplicate of this bug: 1533016
Blocks: 1548155
You need to log in before you can comment on or make changes to this bug.