It doesn't do that on Lucid.

 Issue 48963  has been merged into this issue.

Elliot did a good try at reproducing this problem on his machine, but both ssh -X and Xephyr + ssh -X did not cause it to reproduce for him.  I will need to debug it myself on the Maverick machine I set up.

After setting up my machine with Maverick, I tried using XLIB_SKIP_ARGB_VISUALS=1, which failed to fix it.

Tried using the Lucid version of Ambiance; same issue.

I'm not quite sure this is a problem in chrome. The selected state of highlighted buttons in the xfce panel is identical in its broken color scheme.

I am more confused than ever. I'm going to assume that something is broken that isn't chrome. (Or that xfce is broken in the exact same way so if the xubuntu guys fix this, we can copy their fixes.)

Looks fine here on Lucid/Ambiance. Only Maverick is impacted.

Maverick's gtk2 is 2.21.2 while Lucid has 2.20.1.
XLIB_SKIP_ARGB_VISUALS is not needed atm in Maverick as the client_side_decoration patch has been removed (~ a month ago).

another difference is Cairo, which is a known source of visual artifacts since 1.9.10 when the API was not properly used (by client apps).

How can we make progress on this?
Perhaps we can see if there's a bug in the xfce tracker?

@evan: downgrading cairo to the last version that was in Maverick pre-1.9 (1.8.10-4ubuntu1) fixes the issue so it's a start.

i didn't look at the code but could you isolate that with a small test case?

this may be related..
https://bugs.launchpad.net/ubuntu/+source/gtk2-engines-murrine/+bug/605979

I could see this as murrine doing something bad in its cairo calls. It would explain the multiple application problems and would also explain why changing cairo versions fixes this issue while the code that's drawing is only calling gtk_paint_box() calls.

Just tested this gtk2-engines-murrine patch, it fixes this bug and also many other rendering issues (like the download bar)

Awesome, good to hear!  I will close this bug once the patched fixed version is out.

Benjamin Otte (Cairo dev) and I debugged this.

We found that setting the the "buggy_gradients" field to true on the (cairo private) cairo_xlib_display_t worked around the problem. So it seems likely it's a bug in how the nvidia drivers handle gradients.

It's not clear which layer is responsible for working around this.  Probably Cairo.

http://cairographics.org/news/cairo-1.9.14/ is out with a bunch of clip related fixes

Punting this because there's nothing we can do -- it's a bug in Cairo and GTK.

Bulk moving to mstone 8, at this point work on m7 should effectively be closed.  If something in this bulk edit is not actively being worked on, please change the mstone to m9.

Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting

Moving all P2 bugs w/ owners into Mstone-10.  I'll leave this to the owners discretion if they want to move the work back into M9, however, my caveat would be that the priority should be on completing P0/P1 bugs in the span of the next few weeks.

Closing. The menus look fine in the Maverick release.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.