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

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[Dave Merrill]

Attachment: ff10-overflow-auto-inline-block-bug.html

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

Comment 1

[Dave Merrill]

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.

Thanks.

Comment 2

[Dave Merrill]

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

[Dave Merrill]

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.

Comment 4

[Mats Palmgren (inactive)]

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.

http://www.w3.org/TR/CSS21/visuren.html#inline-formatting
"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

[Mats Palmgren (inactive)]

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

[Dave Merrill]

Attachment: More detailed demo of missing scrollbar

Comment 7

[Dave Merrill]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: 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.

Comment 9

[Mats Palmgren (inactive)]

Attachment: Some shrink-wrapping tests

Comment 10

[Mats Palmgren (inactive)]

Attachment: wip

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

Comment 11

[Mats Palmgren (inactive)]

Attachment: fix+test

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

Try is green:
https://tbpl.mozilla.org/?usebuildbot=1&tree=Try&rev=7024ace3e2f0

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 599585 [details] [diff] [review]
fix+test

r=me

Comment 13

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d82d9b9880a3

Comment 14

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/d82d9b9880a3