On Thu, Apr 27, 2017 at 5:09 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> 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. > > Typing xsync into FvwmConsole did not trigger the removal of the windows. > > 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? > > It kills them before I even get a chance to pick the window to identify. I am not able to find away to get any info on the zombie windows, as soon as I query xorg with xprop or xwinfo, all zombie windows are removed, then it gives me a pointer to pick a window. If I use FvwmIconMan (which still has the windows) to Identify via FvwmIdent (using the window ops menu), the windows disappear and I get no output from FvwmIdent. No errors in .xsession-errors either. jaimos
