Last Comment Bug 397367 - border triggers scrollbar on auto-overflowed block
: border triggers scrollbar on auto-overflowed block
Status: RESOLVED FIXED
[dbaron-1.9:RwCo][needs feedback mats]
: pp, regression, testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: x86 Linux
: P2 normal with 2 votes (vote)
: ---
Assigned To: Mats Palmgren (vacation)
:
Mentors:
: 408579 446297 (view as bug list)
Depends on:
Blocks: 388119 388254 388255 388084
  Show dependency treegraph
 
Reported: 2007-09-24 09:34 PDT by petr.pisar
Modified: 2010-02-16 09:52 PST (History)
17 users (show)
mtschrep: wanted‑next+
mtschrep: blocking1.9-
mats: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase for this bug (599 bytes, application/xml)
2007-09-24 09:37 PDT, petr.pisar
no flags Details
Minimal testcase (465 bytes, text/html)
2007-09-25 11:24 PDT, Mats Palmgren (vacation)
no flags Details
wip1 (7.64 KB, patch)
2007-09-26 16:58 PDT, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review
wip2 (7.90 KB, patch)
2007-09-26 16:59 PDT, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review
Patch rev. 1 (6.12 KB, patch)
2007-12-15 00:14 PST, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review
Patch rev. 1 (diff -w) (5.54 KB, patch)
2007-12-15 00:16 PST, Mats Palmgren (vacation)
dbaron: review-
Details | Diff | Splinter Review
reftest.diff (2.91 KB, patch)
2007-12-15 00:17 PST, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review
screen shot snippet (53.61 KB, image/png)
2009-02-10 13:00 PST, Mike Frysinger
no flags Details

Description petr.pisar 2007-09-24 09:34:54 PDT
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 2007-09-24 09:37:44 PDT
Created attachment 282132 [details]
testcase for this bug

Upper block without border is O.k., lower block with border has needless scroll bar.
Comment 2 Mats Palmgren (vacation) 2007-09-25 11:14:37 PDT
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 (vacation) 2007-09-25 11:24:33 PDT
Created attachment 282282 [details]
Minimal testcase
Comment 4 Boris Zbarsky [:bz] 2007-09-25 12:06:41 PDT
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 [:bz] 2007-09-25 12:08:29 PDT
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 (vacation) 2007-09-26 16:58:12 PDT
Created attachment 282481 [details] [diff] [review]
wip1

Not sure if this is any good but it fixes the testcase and the post-reflow
assertions...
Comment 7 Mats Palmgren (vacation) 2007-09-26 16:59:52 PDT
Created attachment 282482 [details] [diff] [review]
wip2

... slight variation of the above that also seem to work.
Comment 8 Olli Pettay [:smaug] 2007-09-26 23:32:54 PDT
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] 2007-09-27 05:45:19 PDT
(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+2 (mostly busy through August 4; review requests must explain patch) 2007-10-03 16:03:33 PDT
Comment on attachment 282482 [details] [diff] [review]
wip2

>+#include "nsBoxLayoutState.h"

This looks accidental.
Comment 11 Daniel Holbert [:dholbert] 2007-12-11 11:03:38 PST
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 2007-12-11 13:11:46 PST
(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] 2007-12-14 14:30:14 PST
(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] 2007-12-14 14:55:18 PST
I can reproduce on 64bit linux, but not on 32bit.
Comment 15 Boris Zbarsky [:bz] 2007-12-14 20:44:30 PST
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+2 (mostly busy through August 4; review requests must explain patch) 2007-12-14 21:25:12 PST
I don't see a scrollbar on attachment 282282 [details] on either 64bit or 32bit Linux.
Comment 17 Mats Palmgren (vacation) 2007-12-14 23:55:44 PST
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 (vacation) 2007-12-15 00:14:08 PST
Created attachment 293270 [details] [diff] [review]
Patch rev. 1
Comment 19 Mats Palmgren (vacation) 2007-12-15 00:16:04 PST
Created attachment 293271 [details] [diff] [review]
Patch rev. 1 (diff -w)
Comment 20 Mats Palmgren (vacation) 2007-12-15 00:17:04 PST
Created attachment 293272 [details] [diff] [review]
reftest.diff
Comment 21 petr.pisar 2007-12-16 11:06:32 PST
(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 22 Mats Palmgren (vacation) 2007-12-17 03:46:46 PST
*** Bug 408579 has been marked as a duplicate of this bug. ***
Comment 23 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2008-01-29 19:03:53 PST
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) (Exited; email my personal email if necessary) 2008-01-29 20:23:46 PST
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+2 (mostly busy through August 4; review requests must explain patch) 2008-03-11 12:05:15 PDT
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 2008-04-07 18:32:46 PDT
Roc why is this a blocker?
Comment 27 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2008-04-08 00:12:52 PDT
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 2008-04-08 11:37:05 PDT
(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 2008-04-08 12:14:58 PDT
(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 Snover 2008-06-26 18:48:54 PDT
(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 31 Mats Palmgren (vacation) 2008-07-20 11:53:22 PDT
*** Bug 446297 has been marked as a duplicate of this bug. ***
Comment 32 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2008-07-21 03:56:11 PDT
Comment on attachment 293271 [details] [diff] [review]
Patch rev. 1 (diff -w)

Mats, can you answer comment #24?
Comment 33 Mike Frysinger 2009-02-10 13:00:13 PST
Created attachment 361610 [details]
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 2009-06-17 12:05:21 PDT
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 2009-06-17 12:07:41 PDT
BTW, I was seeing this bug on 3.0.3, and still seeing it with 3.5b4.
Comment 36 Mike 2009-10-27 13:56:13 PDT
Is there a workaround for this?
Comment 37 RomD 2009-12-01 11:14:29 PST
Same problem here with 3.5.5 on Ubuntu 9.10 32 bit.
Is there any progress on this?
Comment 38 RomD 2009-12-01 11:45:17 PST
Happens in 3.0.15, too, but is fixed in 3.6b4!
Comment 39 José Jeria 2009-12-02 00:19:00 PST
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+2 (mostly busy through August 4; review requests must explain patch) 2009-12-03 00:44:16 PST
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 2010-02-16 09:52:17 PST
I can confirm this issue has been fixed.

Thank you very much.

Note You need to log in before you can comment on or make changes to this bug.