GNOME Bugzilla – Bug 613911
Progress bar bug
Last modified: 2011-09-18 14:22:45 UTC
Created attachment 157054 [details] screenshot of the problem Debian Release: unstable (sid) 64bit Kernel Linux 2.6.32-4-amd64 GNOME 2.28.2 I can't really explain this bug. I best I can do is say it's a graphics related glitch. When there are GTK+ progress bars in a scroll-able box, the progress bar sometimes goes over the columns like "Name", "Size", "Type" etc. I have attached a screenshot of the problem, because I can't quite explain it.
It looks to me like the engine isn't actually handling clipping. Which theme/engine are you using, and does this still happen if you switch theme?
(In reply to comment #1) > It looks to me like the engine isn't actually handling clipping. Which > theme/engine are you using, and does this still happen if you switch theme? Clearlooks. And yes, with Clearlooks, Glossy, Unity, and any combination of themes using these theme's controls.
Question of comment #1 answered, reopening
After testing here, this bug only affects clearlooks engine. So changing component.
Hrm. There actually is some code in clearlooks to ignore the cliping rectangle, the reason is that it is otherwise impossible to draw the 1px shadow as clearlooks does it. However, I expect that even though clearlooks is ignoring the clip, it should not be able to draw on top of the header window. So this might also be exposing a client side window (CSW) bug.
I worked out steps to reliably produce the error, (in Transmission). It always occurs when moving the cursor from hovering over the column heading to hovering over the progress bar, or vice versa. I reported this incorrectly as a Transmission bug here, for reference: https://trac.transmissionbt.com/ticket/3420
*** Bug 654002 has been marked as a duplicate of this bug. ***
I have committed a fix. commit a0cc71e7f62f355502045747cda973e674d3103b Author: Benjamin Berg <benjamin@sipsolutions.net> Date: Sun Sep 18 16:20:45 2011 +0200 Recreate the cr instead of using cairo_reset_clip. (fixes #613911) It seems like an already active clip is removed if we run cairo_reset_clip, which means that we might draw on top of other things.