Created attachment 70221 [details]
screenshot of rxvt-unicode in action

screenshot

Created attachment 70222 [details]
resources settings

update: in gnome this happens only when "no wallpaper" is selected. I didn't test other desktop environments.

yeah a known bug. i have no solution for this. yet. i will see what i can do about it.

can you try without inheritPixmap?

thanks in advance.

yes, without inheritPixmap it works OK

(forgot to change status)

hmm atm i tend to disable the feature.

unless i find someone to help me with X11 programming or some good quick introduction. marcus do you have a bit time?

the problem seems to be the logic in command.C(2414):intrxvt_term::check_our_parents ()

I cannot find a problem with this feature. I called

  urxvt -tr --tintColor white --shading 50

works for me

it only happens if nothing sets the background.
steps to reproduce:

1. run urxvt-bg-bug.sh
[[[
#!/bin/sh
export DISPLAY=":1"
X $DISPLAY &
PID_X="$!"
metacity &
PID_M="$!"
urxvt -ip -tr --tintColor white --shading 50
kill -TERM $PID_M $PID_X 2> /dev/null
]]]

2. if you than move the window once. the window decoration disappears.

i can easily show this here. i hope the script works for reproducing the bug.

also happens when the background is set, but you don't specify a tintColor.
simplest way to reproduce: urxvt -tr

I tested this and I think it's a windowmanager problem. I called

   urxvt -tr

after I started a plain X-Server with

   X

now I run different windowmangers:

   kwin   -> works
   fvwm2  -> works
   twm    -> works
   wmaker -> works

   metacity -> doesn't work

I assume this depends on the window metacity creates to paint the
border around. The -tr option will copy the pixmap of the parent
window but if the windowmanager doesn't paint its decorations in a
single window it will have the effect that the decorations are
transparent as well

this seems to be not a bug in urxvt

That is possible, but it's coupled with a bug in urxvt as well. Note that when this happens, tinting doesn't work and the pixmap is copied as-is.

...and then there is the thing that i can't make it use negative shading (i.e. to lighten the pixmap instead of darkening it), but that can be only me doing something wrong

yes tinting is a bug, I will have a look. The problem is the call
to 

  XGetWindowProperty

doesn't work if the parent is the root window. That's the reason why
it works if the root window is itself a real window like KDE implements
still investigating

... a bit progress. I patched command.C to be able to obtain the
XA_PIXMAP from the root window if the root window is the original X11
root window:

#if 1
  if (!i || prop == NULL) {
     Atom p = XInternAtom( xdisp, "_XSETROOT_ID", True );
     XGetWindowProperty (xdisp, display->root, p,
                         0L, 1L, False, XA_PIXMAP, &atype, &aformat,
                         &nitems, &bytes_after, &prop);
  }
#endif

ok, but I couldn't manage to create an XImage from the pixmap source
the call to:

  rootpixmap = *(Pixmap *)prop;
  image = XGetImage (xdisp, rootpixmap, sx, sy, nw, nh, AllPlanes, ZPixmap);

failed with a bad match and I don't why. I asked on the list but
currently didn't get an answer...

a variant of this bug is still present in 10.3b2.
steps to reproduce:

1. in GNOME's Appearance control, Wallpaper, choose first item ("no wallpaper")
2. run urxvt -tr

you will see urxvt with window decorations in background color

3. focus urxvt

decorations appear

4. move urxvt around.

decorations disappear, but a border stays around the window

5. focus another window

decorations reappear

i guess this is a bug in GNOME's wm, not in urxvt

apparently, this also happens when a wallpaper is set.

after a short discussion with one of the upstream devs i got a possible workaround.

"urxvt -tr -tint white"

after 8.3 they changed the broken pixmap algorithm. i will look into a backport with him.

the patched version works fine.

thanks for testing. i will submit the fixed package to stable.