Closed Bug 726258 Opened 9 years ago Closed 9 years ago
Horizontal scrollbar doesn't appear on overflow:auto block with horizontal overflow and auto height less than 13
.4px or so
1.17 KB, text/html
5.97 KB, text/html
1010 bytes, text/html
2.03 KB, text/html
6.10 KB, patch
|Details | Diff | Splinter Review|
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
Summary: display: inline-block shuts off overflow: auto scrollbars → display: inline-block shuts off overflow: auto scrollbar
Attachment #596265 - Attachment mime type: text/plain → text/html
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.
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.
Component: Untriaged → Layout: Block and Inline
Product: Firefox → Core
QA Contact: untriaged → layout.block-and-inline
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.
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)
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
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.
Status: UNCONFIRMED → NEW
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
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).
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 on attachment 599585 [details] [diff] [review] fix+test r=me
Attachment #599585 - Flags: review?(bzbarsky) → review+
OS: Windows 7 → All
Hardware: x86_64 → All
Target Milestone: --- → mozilla13
Version: 10 Branch → unspecified
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.