Created attachment 222077 [details]
nautilus-tabs-black-background-adwaita.png

I don't see how this could happen honestly (since that particular notebook area is not even themable on its own), and I can't reproduce with GTK+ 3.5.12, Nautilus 3.5.90 and gnome-themes-standard 3.5.90.1 on current Fedora 18.

Does this happen consistently? Did it start with Nautilus 3.5.90? Any chance you could try to reproduce it with a jhbuild checkout?

Cosimo, I was experiencing this on Fedora 18 around a month or two ago. It didn't happen to every application, but gedit suffered quite a bit from this (the tab bar for both the top and bottom panes), also gnome-terminal and maybe a couple others, but not all apps.

I'm no longer able to reproduce it on the latest Ubuntu Quantal however.

Weird, I've never seen this myself; if it happens intermittently it sounds like a GTK bug rather than a theme one though.
It's difficult to track this down without a reliable way to reproduce it though.

Ok, I'm getting it in gedit also but not gnome-terminal. GTK 3.5.12 with Intel graphics.

Jeremy, is there a particular set of actions that triggers the bug in gedit?
Just to get any possible interactions with the lower levels of the stack out of the picture, does it change anything if you use fallback mode, or force software rendering by e.g. setting LIBGL_ALWAYS_INDIRECT=1 in /etc/bashrc?

Sorry, I should clarify. It wasn't intermittent at the time. There was a period of time when it was always happening, and always with the same apps. The only "intermittency" was that it did not affect every app, but the apps it did affect were permanently stuck that way. There was nothing to "trigger" it, just launch the app and it would be like that.

Unfortunately I'm not currently able to reproduce it though.

The only thing I can think of is 

http://git.gnome.org/browse/gtk+/commit/?id=10423726709539724be0ea19bed76ba4331af774

which was supposed to *fix* instances of black-on-black in evolution

I can reproduce this with nautilus-3.5.91, gtk+-3.5.14, gnome-themes-standard-3.5.91. I can't reproduce this with any version of gedit, or empathy-3.4*, or gnome-terminal-3.4*, or epiphany-3.4*. I have not tried anything else.

Just in case this is a graphics issue; I'm running Intel graphics with mesa-8.0.4, xf86-video-intel-2.20.3, libdrm-2.4.33, kernel 3.5.3. 

The issue persists with `LIBGL_ALWAYS_{SOFTWARE,INDIRECT}=1 nautilus` and with `LIBGL_ALWAYS_SOFTWARE=1 mutter --replace && nautilus`.

`LIBGL_ALWAYS_INDIRECT=1 mutter --replace` causes a segfault, so that wasn't useful.

Just as a shot in the dark, even though the problem is probably in the theme or gtk+, I ran a bisect on nautilus to try to figure out what bit of nautilus is triggering it.

The first bad commit is: http://git.gnome.org/browse/nautilus/commit/?id=469eb89117e199a450aec3411183ed2e9f10f893

The delta is large, but not as large as I thought it would be.

Leaving this on the blocker list for now, since Nirbheek can reproduce and is offering to help debugging this - thanks Nirbheek ! I hope Cosimo will have some time to look into this on Monday.

I tried to investigate this with Nirbheek today, but still to no conclusion.
At the end of the day, this doesn't look like a bug in the theme though, so I'll proceed releasing gnome-themes-standard 3.6.0.

Some other funky facts:
- the bug is not specific to Adwaita, but it also happens in HighContrast
- setting an universal selector in the theme like * { background-color: $foo } also catches the black area and makes the bug go away
- using raw mutter or metacity instead of gnome-shell also makes the bug go away without changes in the theme

In all of these cases, Nirbheek says reverting Nautilus to the commit mentioned in comment #10 makes the bug go away, but I can't really see why that commit would make any difference in how the tab area is rendered.

CC-ing mutter maintainers and Benjamin, they might have a better idea of what's going on here.

Some updates:

(In reply to comment #12)
> - using raw mutter or metacity instead of gnome-shell also makes the bug go
> away without changes in the theme
> 

On #gtk+, Benjamin suggested running with "GTK_DEBUG=no-css-cache" to see if that makes a difference. It did make a difference; now nautilus:

* Always shows a black background with gnome-shell *and* mutter
* Never shows a black background with metacity

(So it got rid of any strange cache effects)

> In all of these cases, Nirbheek says reverting Nautilus to the commit mentioned
> in comment #10 makes the bug go away, but I can't really see why that commit
> would make any difference in how the tab area is rendered.
> 

On #gnome-shell, Magcius suggested checking each hunk to pin the cause down further. Doing that yielded the result, that on that commit, reverting this hunk:

http://git.gnome.org/browse/nautilus/diff/src/nautilus-window.c?id=469eb89117e199a450aec3411183ed2e9f10f893

Also stops it from happening.

moving off the blocker list. this is a rare, deeply mysterious bug that the best minds have not cracked in 2 days, best not to hold the release for it. we'll try to get a fix for 3.6.1, of course

Update:

Inside nautilus_query_editor_handle_event(), when both gtk_widget_realize *and* gtk_widget_event are called, the background for the tabs turns black. Commenting out either call makes it not happen.

The event that is sent to gtk_widget_event can be any key press (I mistakenly thought it happened only with "Ctrl" at first). I verified this by doing a trick to open a new tab without the background becoming black, and then doing a keypress. The trick was:

1) Click on the search button to bring up the search bar
2) Hover over the "+" button till the tooltip appears
3) Press Ctrl+T to open a new tab
[tab background is not black]
4) Press any key
[tab background turns black]

Investigation with Alex L. is showing that the GtkPaned inside the window when the tabs are activated is somehow becoming native at step (4) (the widget heirarchy when tab bg is black is below), when it shouldn't.

0x23045a0: [NautilusWindow] 96,95 886x612 impl(0x2c00003) toplevel abs[0,0] clipbox[{886x612 @0,0}]
    0x23046c0: [NautilusWindow] 886,612 1x1 shaped alpha_bg abs[886,612] clipbox[{empty}]
    0x2304a20: [GtkPaned] 153,41 733x571 impl(0x2c00b0b) alpha_bg abs[0,0] clipbox[{733x571 @0,0}]
        0x27a36c0: [NautilusCanvasView] 0,80 733x491 abs[0,80] clipbox[{733x491 @0,0}]
            0x27a37e0: [NautilusCanvasViewContainer] 0,0 733x491 abs[0,80] clipbox[{733x491 @0,0}]
                0x2648ea0: [NautilusCanvasViewContainer] 0,0 733x491 abs[0,80] clipbox[{733x491 @0,0}]
        0x27a3360: [GtkOverlay] -1,-1 1x1 hidden alpha_bg abs[-1,-1] clipbox[{empty}]
        0x264b240: [GtkOverlay] 564,545 156x25 hidden alpha_bg abs[564,545] clipbox[{empty}]
        0x264b360: [NautilusCanvasView] 0,81 720x489 hidden abs[0,81] clipbox[{empty}]
            0x264b480: [NautilusCanvasViewContainer] 0,0 720x489 hidden abs[0,81] clipbox[{empty}]
                0x264b5a0: [NautilusCanvasViewContainer] 0,0 720x839 abs[0,81] clipbox[{empty}]
    0x2304900: [GtkPaned] 0,41 148x571 alpha_bg abs[0,41] clipbox[{148x571 @0,0}]
        0x2304b40: [NautilusPlacesSidebar] 0,1 148x569 abs[0,42] clipbox[{148x569 @0,0}]
            0x2304c60: [GtkTreeView] 0,0 148x569 abs[0,42] clipbox[{148x569 @0,0}]
                0x2304d80: [GtkTreeView] 0,0 148x569 abs[0,42] clipbox[{148x569 @0,0}]
                0x2304ea0: [GtkTreeView] 0,0 148x28 hidden abs[0,42] clipbox[{empty}]

Alex L. figured out that the gtkimcontextxim module was responsible. A reliable way to reproduce this bug is by running nautilus as follows:

    GTK_IM_MODULE=xim nautilus

Yeah, the issue is two-fold:
a) The xim im module creates a native window for whatever window it get passed events on. This is pretty lame, as we try to avoid native windows as much as possible. If possible we should try to reuse native windows already in the hierarchy rather than create new ones.

b) Nautilus passes gtk_widget_get_window (entry) as event->window when it passes events to the GtkEntry. This is different from the normal input-only child window that the GtkEntry has that is what events normally target. In fact, entry is otherwise no-window, so get_window() returns whatever window the parent widget has, in this case the GtkPaned child window. So, we end up making this window native, which breaks the transparency of it.

2 questions:

(1) I thought we can't ensure_native() later anymore? Didn't Alex remove that code for 3.2 or 3.4 or so? Or was that just the env var to force all windows to be native? In that case: Can we enforce something like that?

(2) Can we fix the xim module to not do this? If the xim module needs an X window, can't it just use the toplevel window?

Also, congrats to Alex for tracking that down. You shall be showered in beer and reddit karma.

(1) For sure we can ensure_native later. Any time you call gdk_x11_window_get_xid() we will on demand convert the window into a native window. I don't see how we can realistically avoid this either atm, as native subwindows are needed for all kinds of integration points like GLX, Xv, Xembed. The way these work right now is that you create your windows as usual, and then when you call _get_xid they will become native for you. 

We don't currently have a way to specify must-be-native up-front with GdkWindowAttr, although that could easily be added.

(2) I don't know XIM but I hope this is possible. It depends on what xim uses the window for. If it uses it for positioning it will not work. If its just a reference it might work, as long as it doesn't have to be unique for each entry or something.

Basically, someone who knows XIM needs to answer this.

XIM needs the XID of the window in the event, because it translates the GdkEvent back into an XEvent to call XFilterEvent on :-(

I think we can maybe make it not use GDK_WINDOW_XID blindly, but only convert input-only windows to native and otherwise walk up the parent chain until it finds a native window.

Alternatively, nautilus could create an input-only child of the entry window just for this purpose.

Finally, we could add an accessor for the input-only window of GtkEntry. But I'd rather avoid that if one of the other methods works.

I'm satisfied with this explanation, but why does GTK_DEBUG=no-css-cache or choice of WM matter?

Matthias: I know that XIM needs an XID for the event. But what does it *do* with that xid. Could we always pass the closest native parent (i.e. usually the toplevel)? Or will this mean XIM will think you're editing a string at the top left corner of the toplevel?

Jasper: Well, the window goes native at some later state, maybe the WM affects when this happens or when the window is redrawn or something. I agree that its kinda weird.

To me, we should investigate why the CSS cache change fixes it.

(In reply to comment #23)
> Matthias: I know that XIM needs an XID for the event. But what does it *do*
> with that xid. Could we always pass the closest native parent (i.e. usually the
> toplevel)? Or will this mean XIM will think you're editing a string at the top
> left corner of the toplevel?

Each XIC has a window it belongs to; I assume that XFilterEvent probably compares the xic window with the event window to determine whether the xic should be given a look at the event.

But couldn't we just use the toplevel window for all XICs? Or does that cause problems?

Really old-style XIM input methods used to create child windows of the passed in window and draw in those child windows. For this reason with GTK+ 2 I kept GtkEntry with an input-output window for the text area in GtkEntry. But if we've switched over to a input-only for that window, then worrying about input methods creating child windows doesn't make sense.

As far as I know, nobody uses XIM for input methods that want preedit or status windows - the only use of XIM I know of is people who want to use the XLib compose code - which is both easy to test and undemanding. I would think that just passing the toplevel (or nearest parent native window) would work fine.

Let's use the toplevel then, because the nearest native window might change and is therefore kinda unpredictable.

Benjamin: Well, the toplevel could conceptually change too, if you reparent. Thats a pretty edgy case though.

If you reparent, you get an unrealize/realize, which recreates all the windows anyway, so widget hierarchy changes are not a concern I don't think.

gtk_window_reparent avoids unrealize/realize if possible, calling gdk_window_reparent() instead.

Eh, gtk_widget_reparent().

Yes, please make sure using XIM for entries in tearoff menus still works after this change.

(In reply to comment #33)
> Yes, please make sure using XIM for entries in tearoff menus still works after
> this change.

entries in tearoff menus ?!
I'll pretend I didn't hear that :-)

Created attachment 225450 [details] [review]
use the toplevel

Nirbheek, can you try this patch ?

(In reply to comment #35)
> Created an attachment (id=225450) [details] [review]
> use the toplevel
> 
> Nirbheek, can you try this patch ?

Fixes the bug for me — nautilus tabs no longer have a black background!

Thanks to everyone for tracking this down. You guys have been great! :)

Nirbheek: Also, does XIM keep working for whatever you used it for?

(In reply to comment #37)
> Nirbheek: Also, does XIM keep working for whatever you used it for?

Yep, it does. My custom compose keys from ~/.XCompose still work with gtk+!

Excellent, lets go with this then.

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

I have pretty much the same problem, only with the file-rename input boxes in Nautilus (originally filed bug 686053), but the patch in comment 35 does not help; it only fixes black tabs but not black input boxes.

(In reply to comment #41)
> I have pretty much the same problem, only with the file-rename input boxes in
> Nautilus (originally filed bug 686053), but the patch in comment 35 does not
> help; it only fixes black tabs but not black input boxes.

I can verify this problem. I didn't notice it because I didn't rename or create any folders.

Steps to reproduce:

1. $ GTK_IM_MODULE=xim nautilus

2. Ctrl+Shift+N to create a new folder

3. Notice that the background of the input box is black

I think bug 686053 needs to be reopened. :(