border triggers scrollbar on auto-overflowed block

RESOLVED FIXED

Status

()

Core
Layout: Block and Inline
P2
normal
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: petr.pisar, Assigned: mats)

Tracking

(Blocks: 3 bugs, {pp, regression, testcase})

Trunk
x86
Linux
pp, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9 -
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:RwCo][needs feedback mats])

Attachments

(5 attachments, 3 obsolete attachments)

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
Created attachment 282132 [details]
testcase for this bug

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

Comment 2

10 years ago
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)
Blocks: 388084
Status: UNCONFIRMED → NEW
Component: General → Layout: Block and Inline
Ever confirmed: true
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Version: unspecified → Trunk
(Assignee)

Updated

10 years ago
Flags: in-testsuite?
Flags: blocking1.9?
(Assignee)

Comment 3

10 years ago
Created attachment 282282 [details]
Minimal testcase
Attachment #282132 - Attachment is obsolete: true
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.
Ah, bug 388254 has the info I was looking for.  Really, we should not be reflowing this scrollbar.  Can we arrange that?
Blocks: 388254, 388255
Summary: border trigers scrollbar on auto-overflowed block → border triggers scrollbar on auto-overflowed block
(Assignee)

Comment 6

10 years ago
Created attachment 282481 [details] [diff] [review]
wip1

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

Comment 7

10 years ago
Created attachment 282482 [details] [diff] [review]
wip2

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

Comment 8

10 years ago
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

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

Seems so.

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

>+#include "nsBoxLayoutState.h"

This looks accidental.
Flags: blocking1.9? → blocking1.9+
Whiteboard: [dbaron-1.9:RwCo]
Priority: -- → P3
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?
(Reporter)

Comment 12

10 years ago
(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.
(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

10 years ago
I can reproduce on 64bit linux, but not on 32bit.
I honestly can't recall whether I reproduced this, and I won't have access to my Linux box until Jan 3.
I don't see a scrollbar on attachment 282282 [details] on either 64bit or 32bit Linux.
(Assignee)

Comment 17

10 years ago
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.)
Keywords: pp
(Assignee)

Comment 18

10 years ago
Created attachment 293270 [details] [diff] [review]
Patch rev. 1
Attachment #282481 - Attachment is obsolete: true
Attachment #282482 - Attachment is obsolete: true
(Assignee)

Comment 19

10 years ago
Created attachment 293271 [details] [diff] [review]
Patch rev. 1 (diff -w)
Attachment #293271 - Flags: superreview?(dbaron)
Attachment #293271 - Flags: review?(dbaron)
(Assignee)

Comment 20

10 years ago
Created attachment 293272 [details] [diff] [review]
reftest.diff
(Assignee)

Updated

10 years ago
Blocks: 388119
(Reporter)

Comment 21

10 years ago
(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)
(Assignee)

Updated

10 years ago
Duplicate of this bug: 408579
Assignee: nobody → mats.palmgren
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).
Attachment #293271 - Flags: review?(roc)
Why are the changes to  nsGfxScrollFrameInner::LayoutScrollbars required? vRect/hRect will shrink down to zero width or height when the scrollbar is collapsed, right?
Priority: P3 → P2
Flags: blocking1.9+

Updated

9 years ago
Flags: tracking1.9+
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.
Attachment #293271 - Flags: superreview?(dbaron)
Attachment #293271 - Flags: review?(dbaron)
Attachment #293271 - Flags: review-
Whiteboard: [dbaron-1.9:RwCo] → [dbaron-1.9:RwCo][needs feedback mats]

Comment 26

9 years ago
Roc why is this a blocker?
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

9 years ago
(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.   
Flags: wanted-next+
Flags: blocking1.9-
Flags: blocking1.9+
(Reporter)

Comment 29

9 years ago
(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

9 years ago
(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]
(Assignee)

Updated

9 years ago
Duplicate of this bug: 446297
Comment on attachment 293271 [details] [diff] [review]
Patch rev. 1 (diff -w)

Mats, can you answer comment #24?
Attachment #293271 - Flags: review?(roc)

Comment 33

8 years ago
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

8 years ago
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

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

Comment 36

8 years ago
Is there a workaround for this?

Comment 37

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

Comment 38

8 years ago
Happens in 3.0.15, too, but is fixed in 3.6b4!

Comment 39

8 years ago
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.
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
(Reporter)

Comment 41

7 years ago
I can confirm this issue has been fixed.

Thank you very much.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.