bug#66398: 29.1; Buggy handling of transparency changes / blur/unblur

[Po Lu]

Tollef Fog Heen <tfheen@err.no> writes:

> The actions I took were:
> - run xprop (initial output up to the first WM_STATE)
> - focus emacs frame (it was still showing as partially transparent at
> this point, as if it had not been focused, this is the next
> _NET_WM_WINDOW_OPACITY and WM_STATE lines
> - move focus back to the terminal I ran xprop in (new set of
> _NET_WM_WINDOW_OPACITY and WM_STAE
> - move focus to emacs again (next WM_STATE + WM_NET_WINDOW_OPACITY
> - M-x (which forces emacs to realise it's in the foreground and repaint
> with the correct transparency), this is (most of) the rest of the output
> - moved focus back to terminal, interrupted xprop
>
> Please let me know if anything is unclear or any other sort of
> information I can provide or experiments/patches to test.

The window property printouts weren't very enlightening.  AFAICT the
opacity is being reset to 1.0 when the frame is focused, but something
promptly reverts it to its former value thereafter.

Would you place a breakpoint on x_set_frame_alpha in xterm.c, more
specifically:

  XChangeProperty (dpy, win, dpyinfo->Xatom_net_wm_window_opacity,
                   XA_CARDINAL, 32, PropModeReplace,
                   (unsigned char *) &opac, 1);

configure it to print a backtrace each time it is hit, and post the
output here?  Repeating the procedure you followed with xprop, of
course.