GtkScrolledWindow widgets (GTK3) have black or transparent backgrounds with Ayatana overlay-scrollbar

I have the same issues, which I was able to fix by removing overlay scrollbars:

sudo apt-get remove overlay-scrollbar*

Status changed to 'Confirmed' because the bug affects multiple users.

Reassigning to ubuntu-gnome-default-settings since I can reproduce on Raring without the GNOME3 PPAs. Specifically, I can reproduce by opening a second document in gedit with the Adwaita theme.

We'll just disable the scrollbars since I think it will be a while before someone fixes bug 1102096 for real and GNOME's own minimal scrollbars work pretty well.

This bug was fixed in the package ubuntu-gnome-default-settings - 13.04.2

---------------
ubuntu-gnome-default-settings (13.04.2) raring; urgency=low

  * Disable the Ubuntu overlay scrollbars since they cause black backgrounds
    in some GTK+ widgets with the Adwaita theme (LP: #1167079, #1102096)
 -- Jeremy Bicha <email address hidden> Sun, 21 Apr 2013 20:31:22 -0400

This bug occures again in ubuntu 14.04.

You can see the problem in Glade when opening the Menu Editor > Hierarchy tab.

Holger, what them are you using, and are you using overlay scrollbars?

^theme

I am using the default Ambiance theme and the Faenza icon set.

Yes overlay scrollbars are on by default. When starting an app from MonoDevelop which disables overlay scrollbars there is no issue.

Holger, you should file a new bug against Ambiance then, because its something different to what this bug is!

try `ubuntu-bug light-themes`!

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

This bug is now affecting the latest release of HandBrake transcoder v0.10.0.
Please let me know if you need further information from my system. Thanks.

does affect fresh installed Ubuntu14.10 too

I disabled the overlay scrollbars with this command:

dconf write /com/canonical/desktop/interface/scrollbar-mode "'normal'"

Which solved the problem for me.
But I would see it as workaround and hope that someone familiar with the GTK solves the problem.

I can see this bug on HandBrake transcoder v0.10.0 too... Look very bad and ugly!

Should this be fixed?

It happens with a fresh 15.04 installation and the handbrake from the 15.04 repository.
However, disabling overlay scrollbars fixes the problem.

I Installed GNOME in Ubuntu 14.04 and this bug happened. I can confirm that executing command from answer #16 fixed the issue.

Can confirm that removing the overlay-scrollbar package resolves this issue on trusty.

I've been using overlay-scrollbars, bzr revision 391 (last to include GTK3 scrollbars) in Archlinux for a while.

I really prefer Ubuntu's design to Gnome's in the case of scrollbars. The Ayatana scrollbars allow for complete elimination of the trough and autohide when not in use. I also like that there are both gtk2 and gtk3 versions so this interface can be consistent between modern and legacy applications.

I'd like to get to the bottom of what went wrong and revive the gtk3 Ayatana scrollbar.

I've been banging my head on the wall over it for a while:
2014: https://bbs.archlinux.org/viewtopic.php?pid=1406902
2017: https://bbs.archlinux.org/viewtopic.php?pid=1699074

The glitches appear to be limited to GtkScrolledWindow, which shouldn't come as much of a surprise. What was the last version of gtk3 in which this didn't happen? 3.18.x?

I note that in 2014 I had this problem with gtk 3.14 and Tim had it with 3.7.12.

Was this working with gtk 3.6?

Also, adding overlay-scrollbar (which actually causes the bug) and Ayatana Design (because I think the Ayatana overlay scrollbars should come back).

I also like that that the overlay scrollbars allow the user to engage scrolling at any point along a scrollable edge, so one doesn't have to hunt down where the scrolling thumb is in the trough.

This was a really good design; it's sad to see it bitrot.

Bug 1367764, seems to have narrowed down the cause and come close to finding a solution.