Horizontal scrollbar doesn't appear on overflow:auto block with horizontal overflow and auto height less than 13.4px or so

RESOLVED FIXED in mozilla13



7 years ago
2 years ago


(Reporter: enigment, Assigned: mats)


(Depends on: 2 bugs, {testcase})

Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [inbound])


(5 attachments, 1 obsolete attachment)



7 years ago
Created attachment 596265 [details]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Steps to reproduce:

Created a div with overflow: auto and white-space: nowrap, with text wider then fits in the window, so it had a horizontal scrollbar. I then gave it display: inline-block.

Actual results:

Div loses horizontal scrollbar when given display: inline-block.

Expected results:

Horizontal scrollbar should still be there.

This is Firefox 10.0.1. None of the other browsers I tested do this:
Chrome 16.0.912.77 m
Safari 5.1.2 7534.52.7
Opera 11.51 Build 1087
IE 9.0.8112.16421


7 years ago
Summary: display: inline-block shuts off overflow: auto scrollbars → display: inline-block shuts off overflow: auto scrollbar


7 years ago
Attachment #596265 - Attachment mime type: text/plain → text/html

Comment 1

7 years ago
Just to be clear, the net effect of this is that an element with the styling described acts as if it had overflow-hidden. There's no indication at all that more text is present than is visible, when in fact there is.

The only workaround I'm aware of is either to remove some of the desired styling, or assign overflow-scroll. As you know, that draws scrollbars whether they're needed or not, pretty undesirable if the element contains only a few words of text.

All of which is to say that I really hope this gets fixed in the 10 branch, ideally soon.


Comment 2

7 years ago
Well, I feel a bit weird saying this, but further testing shows quite inconsistent results in Firefox 10, and similar issues in Chrome 16 and Safari 5.1, but not in IE 9 or Opera 11. I'm unable to explain why my initial tests gave such consistent results, and showed no similar defects in other browsers. I'm not attaching my later tests, as results no longer seem as solidly repeatable as before. 

That said, this is a genuine issue in my real application, one that I'm fairly but not positively sure didn't exist in Firefox 9.

It also appears that:

a) The problem appears only at font sizes 13px and below.

b) Changing it to 14px or higher w js (incl the Firefox dev tools or firebug) and back leaves the scrollbar still visible.

Practically speaking, I'm working around this by setting the font size of the affected element to 14px in css, and having js reset it to my desired 13px. Hacky, and shouldn't be neccessary, but effective.

Comment 3

7 years ago
It further appears that any time js changes whiteSpace to normal and back to nowrap, it's necessary to reapply fontSize = '14px', then after a 1 ms setTimeout, set it back to the desired '13px'.

I realize that most site and apps don't do this, but mine does, and this workaround is necessary in that case.
Component: Untriaged → Layout: Block and Inline
Product: Firefox → Core
QA Contact: untriaged → layout.block-and-inline

Comment 4

7 years ago
Chrome 18.0.1025.3, Opera 12.0 and IE 10 all have the same layout as Firefox -
no scrollbar for the inline-block.  I think this is the correct result.

"When an inline box exceeds the width of a line box, it is split into several boxes and these boxes are distributed across several line boxes. If an inline box cannot be split (e.g., if the inline box contains a single character, or language specific word breaking rules disallow a break within the inline box, or if the inline box is affected by a white-space value of nowrap or pre), then the inline box overflows the line box."

so the whole inline-block overflows the line-box and has the width equal to the
width of its content in your example since the text can't wrap.

If you want it to have the width of the container you can set width:100%
and a scrollbar should appear when the text is wider than that.

Comment 5

7 years ago
Do you have an example where the inline-block have a scrollbar after dynamically
changing some styles? (that is, where the final value for white-space is nowrap)

Comment 6

7 years ago
Created attachment 596420 [details]
More detailed demo of missing scrollbar

Comment 7

7 years ago
My actual app, and also followup tests, do have width 100%. The first test I uploaded was a minimal as I could get it and still see the problem. I'm unclear as to why it no longer does.

Demo #2 is reproducible in Firefox 10, and none of the other tested browsers, at least in the round of testing I just did.

It shows the horizontal scrollbar missing with the indicated styling, at font size of 13px and below. It also shows that raising the font size to 14px in js restores the scrollbar, and that it stays visible after lowering font size back to 13px again with js. Specifics are in the attached file.

Inline-block isn't implicated, far as I can see, regardless of previous results.

I appreciate everyone checking this out, especially in the face of my somewhat inconsistent result reports. *Something* is going on here though.
Attachment #596420 - Attachment mime type: text/plain → text/html
Created attachment 596422 [details]
Minimal testcase based on that second testcase

I'd bet the issue is that that the auto height ends up less than the height of the horizontal scrollbar, so we decide we don't have space to show it or something silly....  I'll double-check that on Monday.
Ever confirmed: true
Summary: display: inline-block shuts off overflow: auto scrollbar → Horizontal scrollbar doesn't appear on overflow:auto block with horizontal overflow and auto height less than 13.4px or so

Comment 9

7 years ago
Created attachment 597906 [details]
Some shrink-wrapping tests

Comment 10

7 years ago
Created attachment 597936 [details] [diff] [review]

We could just remove the size requirement in the minor dimension...
Note the asymmetry in how we treat shrink-wrapped width and height.

This makes us have compatible rendering with Chrome 19 on Windows.

Opera 12 and IE10 appears to treat shrink-wrapped width and height
symmetrically so the vertical scrollbar for the first block in the
"shrink-wrapping tests" doesn't overlap the X.

None of the other UAs suppress the scrollbar like we currently do.

Chrome and Safari does something different on MacOSX though, it
"fades out" scrollbars entirely so you don't see them by default.
Also, the scrollbars does not take up space in layout but overlaps
the content (both vertical/horizontal).
Assignee: nobody → matspal

Comment 11

7 years ago
Created attachment 599585 [details] [diff] [review]

I think we should do this, it's more compatible with other UAs.

Try is green:
Attachment #597936 - Attachment is obsolete: true
Attachment #599585 - Flags: review?(bzbarsky)
Comment on attachment 599585 [details] [diff] [review]

Attachment #599585 - Flags: review?(bzbarsky) → review+

Comment 13

7 years ago
Flags: in-testsuite+
Keywords: testcase
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: [inbound]
Target Milestone: --- → mozilla13
Version: 10 Branch → unspecified
Last Resolved: 7 years ago
Resolution: --- → FIXED


7 years ago
Depends on: 743265


7 years ago
Duplicate of this bug: 747957


7 years ago
Depends on: 762987


2 years ago
Depends on: 1307693
You need to log in before you can comment on or make changes to this bug.