I've talked about this with roc already but it should really be in a bug. The symptom is when you scroll a native scrollbar in an option list it flashes really badly. Scrollbars in gtk2 are NO_WINDOW widgets. That is, they don't actually have their own window underneath them and are just drawn on the window that is part of the parent widget. When you scroll a one of these lists, the window is repainted via an generated expose_event. However, the area underneath the scrollbar is part of that expose event and the view manager, or the frame code (I'm not sure) paints the area black. Once that part of the painting is done the expose event is passed back to the native gtk handlers and the scrollbar is painted on top of that area that was just painted black. The result is the flashing. There are a few options here: o Paint the scrollbar first and then remove the region that contains the scrollbar from the expose area. o Remove child widgets from the paint area and then paint the scrollbar after the expose event has been processed. o Put the native scrollbar into a native window anyway. o Fix the assumption that the area underneath the scrollbar needs to be painted. I'm not sure what the best option is here.

Adding a couple of people who have experience with the paint system and the mac.

Could it have some relation with bug 163805 ?

Could it have some relation with bug 163805 ?

If there is only a few item in a download manager, deleting one will make the vertical scrollbar appear, then disappear. Maybe it is related to this bug. If not, I will file a new one.

*** Bug 187389 has been marked as a duplicate of this bug. ***

*** Bug 187388 has been marked as a duplicate of this bug. ***

*** Bug 184612 has been marked as a duplicate of this bug. ***

*** Bug 199030 has been marked as a duplicate of this bug. ***

We're using gfx scrollbars for everything now so this is "fixed."

Hey, I never thought of this. cool.