Closed
Bug 397367
Opened 17 years ago
Closed 15 years ago
border triggers scrollbar on auto-overflowed block
Categories
(Core :: Layout: Block and Inline, defect, P2)
Tracking
()
RESOLVED
FIXED
People
(Reporter: petr.pisar, Assigned: MatsPalmgren_bugz)
References
(Blocks 3 open bugs)
Details
(Keywords: platform-parity, regression, testcase, Whiteboard: [dbaron-1.9:RwCo][needs feedback mats])
Attachments
(5 files, 3 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
dbaron
:
review-
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/png
|
Details |
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•17 years ago
|
||
Upper block without border is O.k., lower block with border has needless scroll bar.
Assignee | ||
Comment 2•17 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•17 years ago
|
Flags: in-testsuite?
Flags: blocking1.9?
Assignee | ||
Comment 3•17 years ago
|
||
Attachment #282132 -
Attachment is obsolete: true
Comment 4•17 years ago
|
||
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•17 years ago
|
||
Ah, bug 388254 has the info I was looking for. Really, we should not be reflowing this scrollbar. Can we arrange that?
Updated•17 years ago
|
Summary: border trigers scrollbar on auto-overflowed block → border triggers scrollbar on auto-overflowed block
Assignee | ||
Comment 6•17 years ago
|
||
Not sure if this is any good but it fixes the testcase and the post-reflow
assertions...
Assignee | ||
Comment 7•17 years ago
|
||
... slight variation of the above that also seem to work.
Comment 8•17 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•17 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 10•17 years ago
|
||
Comment on attachment 282482 [details] [diff] [review]
wip2
>+#include "nsBoxLayoutState.h"
This looks accidental.
Flags: blocking1.9? → blocking1.9+
Updated•17 years ago
|
Whiteboard: [dbaron-1.9:RwCo]
Priority: -- → P3
Comment 11•17 years ago
|
||
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•17 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.
Comment 13•17 years ago
|
||
(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•17 years ago
|
||
I can reproduce on 64bit linux, but not on 32bit.
Comment 15•17 years ago
|
||
I honestly can't recall whether I reproduced this, and I won't have access to my Linux box until Jan 3.
Comment 16•17 years ago
|
||
I don't see a scrollbar on attachment 282282 [details] on either 64bit or 32bit Linux.
Assignee | ||
Comment 17•17 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•17 years ago
|
||
Attachment #282481 -
Attachment is obsolete: true
Attachment #282482 -
Attachment is obsolete: true
Assignee | ||
Comment 19•17 years ago
|
||
Attachment #293271 -
Flags: superreview?(dbaron)
Attachment #293271 -
Flags: review?(dbaron)
Assignee | ||
Comment 20•17 years ago
|
||
Reporter | ||
Comment 21•17 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: nobody → mats.palmgren
Comment 23•17 years ago
|
||
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?
Updated•17 years ago
|
Priority: P3 → P2
Flags: blocking1.9+
Updated•17 years ago
|
Flags: tracking1.9+
Comment 25•17 years ago
|
||
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•17 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•17 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•17 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•17 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]
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•16 years ago
|
||
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•16 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•16 years ago
|
||
BTW, I was seeing this bug on 3.0.3, and still seeing it with 3.5b4.
Comment 36•15 years ago
|
||
Is there a workaround for this?
Comment 37•15 years ago
|
||
Same problem here with 3.5.5 on Ubuntu 9.10 32 bit.
Is there any progress on this?
Comment 38•15 years ago
|
||
Happens in 3.0.15, too, but is fixed in 3.6b4!
Comment 39•15 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.
Comment 40•15 years ago
|
||
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•15 years ago
|
||
I can confirm this issue has been fixed.
Thank you very much.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•