397367 - border triggers scrollbar on auto-overflowed block

Status: RESOLVED FIXED

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

Description

[petr.pisar]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8) Gecko/2007091211 GranParadiso/3.0a8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8) Gecko/2007091211 GranParadiso/3.0a8

Having block element with attribute overflow: auto which fits into parent element and which has border shows partially drawn horizontal scrollbar.

Reproducible: Always

Steps to Reproduce:
Render block with style="overflow: auto; border: solid".
Actual Results:  
The horizontal scrollbar is partially rendered.

Expected Results:  
No scrollbar is visible.

Maye similar to bug #308408.

Comment 1

[petr.pisar]

Attachment: testcase for this bug

Upper block without border is O.k., lower block with border has needless scroll bar.

Comment 2

[Mats Palmgren (inactive)]

Regression window:  2007080204 -- 2007080304.
It was caused by bug 388084, by the PR_MAX that was introduced here:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/base/nsPresShell.cpp&rev=3.1063&root=/cvsroot&mark=6104#6098

for both v/h scrollbar frames I see size.height=0 and
reflowState.mComputedBorderPadding.TopBottom()=120
(removing the PR_MAX makes the problem disappear - I'm not suggesting that's
the fix)

Comment 3

[Mats Palmgren (inactive)]

Attachment: Minimal testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

We've run into this with scrollbars before (not sure where; bug 366791 is the closest I can find right now).

Basically, the scrollbars, when collapsed, are sizing smaller than they possibly should based on their reflow state.  Which means we need to somehow teach the reflow state about this scrollbar behavior so it can properly compute things in that case.... or something.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah, bug 388254 has the info I was looking for.  Really, we should not be reflowing this scrollbar.  Can we arrange that?

Comment 6

[Mats Palmgren (inactive)]

Attachment: wip1

Not sure if this is any good but it fixes the testcase and the post-reflow
assertions...

Comment 7

[Mats Palmgren (inactive)]

Attachment: wip2

... slight variation of the above that also seem to work.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 282482 [details] [diff] [review]
wip2

Very close to what I was testing (but I didn't get it quite right). 

>   // place the scrollcorner
>   if (mScrollCornerBox) {

Does scrollcorner get invalidated properly when you resize window so that
scrollbars become visible or hidden?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #8)
> Does scrollcorner get invalidated properly when you resize window so that
> scrollbars become visible or hidden?

Seems so.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 282482 [details] [diff] [review]
wip2

>+#include "nsBoxLayoutState.h"

This looks accidental.

Comment 11

[Daniel Holbert [:dholbert]]

This WORKSFORME using current nightly on Linux
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007121008

However, this also WORKSFORME using a nightly from around when this bug was filed:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007092504

(I see no scrollbars on either testcase, in both of those builds)

To those who've seen the bug in action -- any hints on reproducing it?  And is it still broken in current trunk?

Comment 12

[petr.pisar]

(In reply to comment #11)
It has never worked for me on any Firefox3 build since report day of this bug. (I've been using nigthbuilds since FF3beta1 release.) Today's nightbuild (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007121108) suffers from this bug too, yesterday's nigtbuld either.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to comment #12)
> It has never worked for me on any Firefox3 build since report day of this bug.
> (I've been using nigthbuilds since FF3beta1 release.) Today's nightbuild
> (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007121108) suffers
> from this bug too, yesterday's nigtbuld either.

Weird... I still see no scrollbars on either of the attached testcases.  I just tested a fresh trunk checkout from today.

Any tips on how to reproduce the bug?  

Boris / smaug / mats, have you guys been able to reproduce this, and do you still see it?

(Also: you're seeing it in even in freshly-created profiles with no extensions installed, right?)

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

I can reproduce on 64bit linux, but not on 32bit.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I honestly can't recall whether I reproduced this, and I won't have access to my Linux box until Jan 3.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't see a scrollbar on attachment 282282 [details] on either 64bit or 32bit Linux.

Comment 17

[Mats Palmgren (inactive)]

I can still reproduce it with both testcases using a 64-bit debug build
and a 32-bit nightly build on Linux, with a fresh profile.
(I've never seen this problem on Windows or MacOSX.)

Comment 18

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Comment 19

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1 (diff -w)

Comment 20

[Mats Palmgren (inactive)]

Attachment: reftest.diff

Comment 21

[petr.pisar]

(In reply to comment #13)
> (Also: you're seeing it in even in freshly-created profiles with no extensions
> installed, right?)
> 
Positive. I've just tested it under fresh profile with the same result.

According others, may be it depends on external libraries. This is list of Gentoo packages owning librararies used by firefox

$ ldd firefox-bin |awk '{if (!/not found/) {print $3}}'|xargs -- qfile -v --
x11-libs/libXdamage-1.1.1 (/usr/lib/libXdamage.so.1)
x11-libs/gtk+-2.12.1-r2 (/usr/lib/libgdk-x11-2.0.so.0)
x11-libs/gtk+-2.12.1-r2 (/usr/lib/libgtk-x11-2.0.so.0)
x11-libs/gtk+-2.12.1-r2 (/usr/lib/libgdk_pixbuf-2.0.so.0)
x11-libs/libXi-1.1.3 (/usr/lib/libXi.so.6)
x11-libs/libXcursor-1.1.8 (/usr/lib/libXcursor.so.1)
x11-libs/libXrandr-1.2.1 (/usr/lib/libXrandr.so.2)
x11-libs/libXfixes-4.0.3 (/usr/lib/libXfixes.so.3)
x11-libs/pango-1.18.3 (/usr/lib/libpangocairo-1.0.so.0)
x11-libs/pango-1.18.3 (/usr/lib/libpangoft2-1.0.so.0)
x11-libs/pango-1.18.3 (/usr/lib/libpango-1.0.so.0)
x11-libs/libX11-1.1.3 (/usr/lib/libX11.so.6)
x11-libs/libXau-1.0.3 (/usr/lib/libXau.so.6)
x11-libs/libXdmcp-1.0.2 (/usr/lib/libXdmcp.so.6)
x11-libs/libXrender-0.9.4 (/usr/lib/libXrender.so.1)
x11-libs/cairo-1.4.12 (/usr/lib/libcairo.so.2)
x11-libs/libXcomposite-0.4.0 (/usr/lib/libXcomposite.so.1)
x11-libs/libXext-1.0.3 (/usr/lib/libXext.so.6)
sys-devel/gcc-4.1.2 (/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1)
sys-devel/gcc-4.1.2 (/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6)
dev-libs/atk-1.20.0 (/usr/lib/libatk-1.0.so.0)
dev-libs/nspr-4.6.7 (/usr/lib/nspr/libnspr4.so)
dev-libs/nspr-4.6.7 (/usr/lib/nspr/libplc4.so)
dev-libs/nspr-4.6.7 (/usr/lib/nspr/libplds4.so)
dev-libs/glib-2.14.4 (/usr/lib/libglib-2.0.so.0)
dev-libs/glib-2.14.4 (/usr/lib/libgobject-2.0.so.0)
dev-libs/glib-2.14.4 (/usr/lib/libgmodule-2.0.so.0)
dev-libs/libxml2-2.6.30 (/usr/lib/libxml2.so.2)
sys-libs/zlib-1.2.3-r1 (/lib/libz.so.1)
sys-libs/glibc-2.6.1 (/lib/libpthread.so.0)
sys-libs/glibc-2.6.1 (/lib/libm.so.6)
sys-libs/glibc-2.6.1 (/lib/libdl.so.2)
sys-libs/glibc-2.6.1 (/lib/libc.so.6)
media-libs/fontconfig-2.4.2 (/usr/lib/libfontconfig.so.1)
media-libs/libpng-1.2.22 (/usr/lib/libpng12.so.0)
media-libs/freetype-2.3.4-r2 (/usr/lib/libfreetype.so.6)

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 293271 [details] [diff] [review]
Patch rev. 1 (diff -w)

Requesting review from roc instead of me (working around bugzilla brokenness, so he can plus original requests).

Comment 24

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

Why are the changes to  nsGfxScrollFrameInner::LayoutScrollbars required? vRect/hRect will shrink down to zero width or height when the scrollbar is collapsed, right?

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 293271 [details] [diff] [review]
Patch rev. 1 (diff -w)

I'm going to minus the review request to me pending an answer to roc's question; you should probably re-request to roc rather than to me.

Comment 26

[Mike Schroepfer]

Roc why is this a blocker?

Comment 27

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

It's a layout regression with a simple testcase that seems like it would be likely to occur in the wild, but since we have no report of that I guess we can take it off the blocker list. That fact that it's hard to reproduce both increases and decreases the need to block on it...

Comment 28

[Mike Schroepfer]

(In reply to comment #27)
> It's a layout regression with a simple testcase that seems like it would be
> likely to occur in the wild, but since we have no report of that I guess we can
> take it off the blocker list. That fact that it's hard to reproduce both
> increases and decreases the need to block on it...
> 

Ok - I'm gonna take it off the list.   

Comment 29

[petr.pisar]

(In reply to comment #27)
> we have no report of that
I can provide you this bug in wild: http://uhercice.ipv6ia.org/

Comment 30

[Colin S]

(In reply to comment #27)
> It's a layout regression with a simple testcase that seems like it would be
> likely to occur in the wild, but since we have no report of that I guess we can
> take it off the blocker list. That fact that it's hard to reproduce both
> increases and decreases the need to block on it...
> 

This occurs at http://framework.zend.com/manual/en on all of the code example boxes that aren't wide enough to overflow. I've also seen it on at least two other sites, but don't recall the URLs. This only seems to happen on Linux -- at least, I can't reproduce it on my Mac. Could it be related to either bug #435655 or bug #420170?

[Running Kubuntu 8.04 using the "Use my KDE style in GTK applications" option. Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008061017 Firefox/3.0]

Comment 32

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

Comment on attachment 293271 [details] [diff] [review]
Patch rev. 1 (diff -w)

Mats, can you answer comment #24?

Comment 33

[Mike Frysinger]

Attachment: screen shot snippet

it occurs with many dokuwiki sites "in the wild".  that's how i noticed the issue in the first place:
https://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:debugging#jtag_loading

ive seen this on many of my Gentoo installs, but atm i'm using 32bit x86 w/KDE-3.5

the (mostly) reduced html code from the dokuwiki sites:
<html><body>
<style type='text/css'>
pre { padding:5em; border:1px dashed #8cacbb; overflow:auto; }
</style>
<pre></pre>
</body></html>

Comment 34

[Mike]

Another real-world example of this bug in action:
http://www.beta.reddit.com/comments/8t2th/w

The blue box with rounded corners exhibits this just beneath "PS - Cookies will behave strangely".

It looks like in this case, the horizontal scrollbar is compressed to being a single pixel tall. This results in the bottom border being rendered in gray instead of blue, and extending past the rounded corners.

Oddly, if I go into Firebug and turn the border off and then back on, the problem goes away.

Comment 35

[Mike]

BTW, I was seeing this bug on 3.0.3, and still seeing it with 3.5b4.

Comment 36

[Mike]

Is there a workaround for this?

Comment 37

[RomD]

Same problem here with 3.5.5 on Ubuntu 9.10 32 bit.
Is there any progress on this?

Comment 38

[RomD]

Happens in 3.0.15, too, but is fixed in 3.6b4!

Comment 39

[José Jeria]

WFM:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091201 Minefield/3.7a1pre

"Minimal testcase" in comment 3 and code example in comment 33 were tested.

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Seems likely to have been fixed by these changes:
http://hg.mozilla.org/mozilla-central/rev/4e85941dfbb5
http://hg.mozilla.org/mozilla-central/rev/8ea02ebd43f0

Comment 41

[petr.pisar]

I can confirm this issue has been fixed.

Thank you very much.