On Thu, Apr 27, 2017 at 05:00:33PM -0600, Jaimos Skriletz wrote: > On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > > On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote: > >> Sometimes when a process stops the window will remain open until some > >> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm > >> will remove the window. > > > > That is not possible unless either > > ... > > The process do not appear in 'ps fax' and the script outputs [Done] on > all the jobs that were run in the background in the shell, so this is > not the case. > > > 2) the X server has a bug, > > This does seem to be the case. The user and myself both tested this > running an xsession with only an xterm. We could not reproduce it with > only running an xterm. > > I decided to test another window manager, openbox in this case, and > was able to reproduce the issue in openbox. So it seems to be some bug > with how the xserver but may require a window manager to trigger it.
I wonder what that trigger could be. If the window can be moved, fvwm is communicating with the X server in both directions, so if a destroy event was pending it should have been delivered to fvwm before any mouse motion events. Maybe the X server itself has destroyed the window internally but not yet sent the event for some reason, and does so only when some request for that window is issued. (Moving the fvwm window does not move the client window directly but the frame.) If you type "xsync" in FvwmConsole, does that kill the window? (This forces all pending requests and events to be delivered in both directions.) My guess is that it doesn't, i.e. no event is pending. > In all cases trying to get any info from the xserver closes the > windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo > will close all the windows that were left open when running that > command. Does it also kill the window to request information from a different (non-zombie) window? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
