691000 - Missing horizontal scroll bar with overflow:auto; when height of scrollable area is very small

Status: NEW

(Core :: Web Painting, defect)

Description

[Mark A. Ziesemer]

Attachment: Minimal HTML test case.

This is a rendering issue that presents itself under Windows 7, but not under Windows XP.

Basically, a <pre/> block with overflow:auto; is not displaying the scroll bars as expected when the text content overflows - when combined with some font-size settings.  This causes information to appear missing - sometimes omitting critical information from the viewing user.

A minimal test case is attached, which includes the following CSS:

pre{overflow:auto;}
.wiki-content{font-size:10pt;}
.panelContent{font-size:.95em;}

When viewed, if the complete "-S" argument is not viewable on the screen, scroll bars should be visible to scroll and view the complete content of the <pre/> element.

When there is an element that matches "div.wiki-content div.panelContent pre" with text that overflows, the scroll bars are not displayed as expected.  However, the hidden text can still be viewed by causing it to scroll into view by doing a moving select on the text with the mouse, or by using the arrow keys.

Using Firebug, disabling the font-size attribute within the panelContent CSS class causes the scroll bars to immediately appear.  Interestingly, re-enabling the attribute does not cause the scroll bars to disappear again.  Removing the attribute from the code entirely causes the scroll bars to appear as expected on page load, while any font size < 1em seems to continue the issue.

Removing the font-size attribute from the wiki-content CSS class instead causes results that I haven't been able to reproduce consistently yet.  In some cases, it seems to cause the scroll bars to appear on the containing window, instead of on the <pre/>.  In other cases, the scroll bars don't appear at all.

I have reproduced this on several computers running Windows 7 (both x64, SP1): Any version of Firefox tested - including 3.6 to 7.0.1 demonstrates the issue. IE and Chrome on the same systems show the scroll bars as expected.

I have not been able to reproduce this under Windows XP - including Firefox 3.6 and 7.0.

See also: https://jira.atlassian.com/browse/CONF-23356 .  (This was originally found against the Atlassian Confluence Wiki product, version 3.5.13.)

Comment 1

[Alice0775 White]

Confirmend on  Firfox4.0 to Nightly9.0a1 with HWA on.
http://hg.mozilla.org/mozilla-central/rev/b5b082d183d0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110930 Firefox/10.0a1 ID:20110930030850

This does not happen without HWA.

Comment 2

[Alice0775 White]

regression range with force enabled Diorect2D and DirectWrite.

Regression window,
Works:
http://hg.mozilla.org/mozilla-central/rev/575fe0710b22
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100225 Minefield/3.7a2pre ID:20100225132211
Fails:
http://hg.mozilla.org/mozilla-central/rev/0e1c0b71bf13
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100225 Minefield/3.7a2pre ID:20100225230231
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=575fe0710b22&tochange=0e1c0b71bf13
Triggered by:
0e1c0b71bf13	Bas Schouten — Bug 527707: Add Direct2D and DirectWrite backend integration to thebes and widget. Preffed off by default r=jrmuizel r=jmathies r=jfkthame

Comment 3

[Alex]

I see the same problem on OS X (Lion + 10.0a1 Nightly), so it's not just a Windows 7 issue.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is pretty bad. Jonathan, can you look into it?

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: reduced testcase showing the bug on Mac OS X

On OS X (10.6, running a Nightly build) I can reproduce the problem with a further-simplified testcase, as attached. No <div>s or font-size properties needed.

When I initially load this on OS X, the expected scroll bar is missing. Zooming in makes it appear, and zooming back out retains it (as described above). Zooming out far enough that all the text is visible makes it disappear again (as expected), but then zooming back in does not restore it until reaching a greater-than-100% zoom level.

Comment 6

[Jonathan Kew [:jfkthame]]

On Win7, I can reproduce with HWacc both on and off (unlike Alice in comment 1).

Comment 7

[Jonathan Kew [:jfkthame]]

Removing "regression" keyword, as this issue has existed since (at least) FF3.6, per comment 0; also reproduced locally with FF3.6 on OS X and on Linux.

Comment 8

[Alice0775 White]

(In reply to Jonathan Kew (:jfkthame) from comment #6)
> On Win7, I can reproduce with HWacc both on and off (unlike Alice in comment
> 1).

Yes.
It only happens with HWacc on if  Windows 7 Visual style is "Classic".
It happens with HWacc both on and off if Windows 7 Visual style is "Aero" and "AeroBasic".

Comment 9

[Alice0775 White]

I found strange behavior.

The scroll bar appears, if  minimum font size set to larger than 14(windows7), 15(ubuntu) in preferences.

Comment 10

[Alice0775 White]

Regression window Windows XP Luna (this does not happen on XP Classc) without HWA :
Works:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050428 Firefox/1.0+
Fails:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050429 Firefox/1.0+
Pushlog:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-28+01%3A00%3A00&maxdate=2005-04-29+03%3A00%3A00&cvsroot=%2Fcvsroot

Comment 11

[Jonathan Kew [:jfkthame]]

Attachment: testcase demonstrating the dependency on height of scrollable area

The problem arises if the height of the potentially-scrollable area is less than the height of a horizontal scrollbar on the platform.

This testcase has two <div>s that should both be horizontally scrollable, but the one with height:10px will not display its scrollbar, while the one with height:20px will display it as expected.

Zooming in will enlarge the <div>s but not change the default metrics of scrollbars, and so this will eventually cause the scrollbar to appear even on the <div> with the smaller height. Once the scrollbar is visible, this state persists because nsHTMLScrollFrame prefers to avoid changing the visibility of its scrollbars when reflowing.

Comment 12

[Jonathan Kew [:jfkthame]]

Attachment: patch, don't suppress horizontal scrollbar below element with very small height

So this seems to fix the problem, by eliminating the requirement that the scrollable element is at least as high as the scrollbar - that looks as though it was intended for cases where the scrollbar appears _within_ the bounds of the element being scrolled, but in the testcases here, at least, it's being placed _outside_ and so there's no reason to suppress it for narrow elements.

Roc, will this upset assumptions that are being elsewhere if we just remove this test? It passes all unit tests on try, so I guess either it's OK, or else we don't have an appropriate test to detect what it'll break!

(We should also be able to have a reftest for this, based on the above testcases.)

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think this will break cases where the height of the scrollable element is not auto. When the element height is less than the height of the horizontal scrollbar, things will go wrong.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Note that the horizontal scrollbar is always inside the border. It just so happens that these testcases are height:auto so the border-box expands to include the scrollbar.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The code does have
  desiredInsideBorderSize.height = hScrollbarDesiredHeight +
    NS_MAX(aKidMetrics->height, vScrollbarMinHeight);
so I would expect aState->mInsideBorderSize to include the height of the horizontal scrollbar, and therefore aState->mInsideBorderSize.height > hScrollbarMinSize.height.

Is it possible that hScrollbarDesiredHeight < hScrollbarMinSize.height?

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #15)
> The code does have
>   desiredInsideBorderSize.height = hScrollbarDesiredHeight +
>     NS_MAX(aKidMetrics->height, vScrollbarMinHeight);
> so I would expect aState->mInsideBorderSize to include the height of the
> horizontal scrollbar, and therefore aState->mInsideBorderSize.height >
> hScrollbarMinSize.height.
> 
> Is it possible that hScrollbarDesiredHeight < hScrollbarMinSize.height?

Yes, certainly - TryLayout is called (first) with aAssumeHScroll=false (as the frame hasn't previously been laid out with scrollbars), and so hScrollbarDesiredHeight is zero. Hence, it makes no contribution to desiredInsideBorderSize.height, and so mInsideBorderSize.height ends up very small. This forces wantHScrollbar to false, whereas it otherwise would have been true; and this matches aAssumeHScroll, which allows TryLayout to (inappropriately) return true.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I see. So we assumed there wasn't a horizontal scrollbar, so we didn't allocate room for one, so there isn't room for one, so we decide our assumption was valid :-).

I'm not sure how to fix this. The current algorithm gives us a consistent layout, but not the best one. Maybe instead of returning a bool, TryLayout should return a score: "unacceptable", "consistent", and "good". TryLayout would return "consistent" for any layout that hides a scrollbar due to insufficient space. nsHTMLScrollFrame::ReflowContents could then keep its current structure, returning immediately anytime we find a "good" layout, but remembering any "consistent" layout that we find. At the end, if we haven't found a "good" layout, use the first "consistent" layout we found (and if we haven't even found a "consistent" layout, use the existing fallback).