Last Comment Bug 297508 - GTK2 scrollbars pixel artifacts when scrolling near bottom
: GTK2 scrollbars pixel artifacts when scrolling near bottom
Status: VERIFIED FIXED
: fixed1.8, polish, regression
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-12 18:51 PDT by Sam Allen
Modified: 2013-01-12 22:49 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (11.59 KB, patch)
2005-06-23 23:39 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
bryner: review+
blizzard: superreview+
asa: approval1.8b4+
Details | Diff | Splinter Review

Description Sam Allen 2005-06-12 18:51:15 PDT
On GTK themes that have a dark border on the bottom part of the scrollbar thumb,
scrolling either with the mouse, arrow keys, or scroll wheel leaves artifacts on
the scrollbar. This only occurs on either short pages or the bottom of medium
size pages. The artifacts are one-pixel tall horizontal grey lines on the
scrollbar. This occurs with the Ubuntu Human theme, and Clearlooks, but not
Glider (because is has a bottom border that is the same color as the background
of the scrollbar). The scrollbar paints itself properly when you click outside
of the window or hover the mouse over the scrollbar.

This is a serious polish regression and needs to be fixed for the next major
release.

I am CC'ing roc@ocallahan.org because I think this problem might have surfaced
with the new scrollbar stuff that landed. (I haven't verified that this is the
case yet.)

Again, to reproduce:
0. Make sure you are using an affected theme (should have dark pixel border on
the bottom of the scroller).
1. Go to a short page that takes up maybe 2 vertical viewports.
2. Scroll to the bottom of the page, and then up in the bottom half.
3. Artifacts should appear.
Comment 1 Andrew Schultz 2005-06-12 21:25:46 PDT
I see this with suite gtk2 builds (with classic theme) back to at least 12/9/2004
Comment 2 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-06-23 20:46:39 PDT
I've been digging into this bug. It looks like a couple of themes (Ximian
Industrial, Misty, maybe others ... I don't have Bluecurve here) have a problem
where we call gtk_paint_slider requesting thumb height 404 and they paint a
thumb of height 405.

I see that blizzard added code here
http://lxr.mozilla.org/mozilla/source/gfx/src/gtk/gtk2drawing.c#741
to expand the clip rect. I think this is incorrect because it allows us to draw
outside the frame, and then that doesn't get cleaned up when we need to
invalidate the frame.

I'll try to fix this by instead decreasing the requested height.
Comment 3 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-06-23 23:39:30 PDT
Created attachment 187190 [details] [diff] [review]
fix

I think this is the right way to fix this. We allow the clip rect to increase.
We handle that the "right way" by including the increase to the thumb frame's
overflow area --- so layout knows that this extra area will be painted by the
frame. And we have to fix nsSliderFrame to use the thumb frame's overflow area
for invalidation. This fixes the bug without changing the scrollbar appearance.
The new GetWidgetOverflow method is also a nice general mechanism that could be
useful later in other situations.
Comment 4 Christopher Blizzard (:blizzard) 2005-08-26 07:41:49 PDT
Comment on attachment 187190 [details] [diff] [review]
fix

Seems fine to me.
Comment 5 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-08-31 14:14:11 PDT
I checked this in. I'll wait for a couple of days and then submit to the branch.
Comment 6 Adam Guthrie 2005-09-02 14:25:15 PDT
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050901 Firefox/1.6a1
ID:2005090120

Haven't noticed this since the patch went in. I'd say it's ready for branch.
Comment 7 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-09-02 15:45:30 PDT
Comment on attachment 187190 [details] [diff] [review]
fix

I want to land this on the branch. It fixes a signficant problem with visual
garbage in some common GTK2 themes.
Comment 8 Asa Dotzler [:asa] 2005-09-02 16:50:25 PDT
Roc, what's the risk here and what kinds of regressions should we keep an eye
out for after this lands?
Comment 9 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-09-02 16:57:43 PDT
The risk is extremely low for non-GTK2 platforms. On GTK2 any bugs would likely
be confined to weird scrollbar behaviour.
Comment 10 Asa Dotzler [:asa] 2005-09-04 10:13:29 PDT
time is short for beta so if this is gonna make the branch, it needs to land ASAP.
Comment 11 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-09-04 12:58:19 PDT
checked into branch.
Comment 12 Siim Ainsaar 2013-01-12 22:49:39 PST
The bug seems to have resurfaced as bug 828824.

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