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.
Div loses horizontal scrollbar when given display: inline-block.
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
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.
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.
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.
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.
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)
Created attachment 596420 [details]
More detailed demo of missing scrollbar
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.
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.
Created attachment 597906 [details]
Some shrink-wrapping tests
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).
Created attachment 599585 [details] [diff] [review]
I think we should do this, it's more compatible with other UAs.
Try is green:
Comment on attachment 599585 [details] [diff] [review]
*** Bug 747957 has been marked as a duplicate of this bug. ***