Subject: AutoRaise problem...

From: "Paul D. Smith" <[email-masked]>
Date: 20 Apr 2001 10:42:09 -0400

I'm seeing a problem in the very latest CVS code (and for a week or so
as well), with FvwmAuto (FvwmAuto 500).

This is with rxvt's, but I have no reason to believe it wouldn't happen
with other windows too.

What happens is when I de-iconify (using mouse-2 on an icon, which is
just bound to "Iconify"), if I zoom the cursor to where the window will
appear when de-iconified right after I click it, so that my cursor gets
there before or at the same time as the window appears, then it won't
get focus.  I have to move the mouse to the border, then FVWM "notices"
I'm really in the window and gives it focus.

It doesn't happen in my Gnome session at work (where iconification is to
the Gnome panel) but it's easy to reproduce on my system at home, where
I just use straight FVWM.  I also use FvwmAnimate to animate the
iconification/deiconification; I think that might help show the problem
by making it easier to get the mouse there before the window opens.

I vaguely recall having a similar problem a few months ago, which was
fixed, but now it seems to be back.

Unfortunately I spent all last night reloading Windows98 on my Windows
partition (what a piece of crap!) and didn't have time to track this
down more carefully.

If you can't reproduce it based on the above description I'll play with
it more this weekend.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 20 Apr 2001 17:00:56 +0200

> If you can't reproduce it based on the above description I'll play with

C'est la vie.  Sorry, we can choose between several unwanted
behaviours here.  The alternative is to screw up functions that
modify the focus but do not move the pointer to the focus window.
Grabbing and releasing the pointer generates EnterNotify and
LeaveNotify events.  These can either be thrown away or used to
transfer focus.  Throwing them away triggers the problem you
describe, using them makes windows take the focus away from
another window in functions under certain circumstances.  Since
there is no way to distinguish between wanted and unwanted events,
I don't know what to do about it.

The older code that worked in this situation broke other things.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: "Paul D. Smith" <[email-masked]>
Date: 20 Apr 2001 11:14:40 -0400

>> I'm really in the window and gives it focus.

  dv> Throwing them away triggers the problem you describe, using them
  dv> makes windows take the focus away from another window in functions
  dv> under certain circumstances.  Since there is no way to distinguish
  dv> between wanted and unwanted events, I don't know what to do about
  dv> it.

  dv> The older code that worked in this situation broke other things.

Ugh.  This kind of bites.

Can we quantify more precisely the alternatives?  We know what happens
the way it is now, and it's pretty annoying and happens almost every
time I de-iconify a window.  What exactly is the behavior that breaks
when the code works the other way?

---

From: Dan Espen <[email-masked]>
Date: Fri, 20 Apr 2001 11:24:13 -0400

> > This is with rxvt's, but I have no reason to believe it wouldn't happen

I just tried to recreate this problem and ended up with a core file.

I run FvwmAuto with 200.
I wasn't able to duplicate the problem as Paul described but after a while
with FvwmAuto still running, an rxvt and XEmacs started a battle amongst
themselves over who was going to be on top.  Without the mouse moving at
all they just kept switching places.

After I moved the pointer out of the disputed area, the battle came
to an end.  (I won't mention who won, its not important.)

The next thing I did was run something I'm testing from an rxvt that creates
an rxvt window.  The window opens and closes by itself.  Thats when I got this
core dump:

#0  0x35bf0 in remove_window_from_stack_ring (t=0xc45f0)
    at ../../version-2_3_32/fvwm/stack.c:171
171       t->stack_next->stack_prev = t->stack_prev;
(gdb) where
#0  0x35bf0 in remove_window_from_stack_ring (t=0xc45f0)
    at ../../version-2_3_32/fvwm/stack.c:171
#1  0x3649c in RaiseOrLowerWindow (t=0xc45f0, do_lower=0, allow_recursion=0, 
    is_new_window=1) at ../../version-2_3_32/fvwm/stack.c:598
#2  0x35dd4 in position_new_window_in_stack_ring (t=0xc45f0, do_lower=0)
    at ../../version-2_3_32/fvwm/stack.c:259
#3  0x55ab0 in AddWindow (w=532480, ReuseWin=0xffbed0d8)
    at ../../version-2_3_32/fvwm/add_window.c:1438
#4  0x39334 in HandleMapRequestKeepRaised (KeepRaised=0, ReuseWin=0x0)
    at ../../version-2_3_32/fvwm/events.c:1029
#5  0x3927c in HandleMapRequest () at ../../version-2_3_32/fvwm/events.c:993
#6  0x3bcc0 in DispatchEvent (preserve_Tmp_win=0)
    at ../../version-2_3_32/fvwm/events.c:2715
#7  0x3bd90 in HandleEvents () at ../../version-2_3_32/fvwm/events.c:2768
#8  0x5c45c in main (argc=2, argv=0x840e4)
    at ../../version-2_3_32/fvwm/fvwm.c:742
(gdb)

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Fri, 20 Apr 2001 11:41:28 -0400

> I just tried to recreate this problem and ended up with a core file.

Just got the core again without FvwmAuto.

Basically, all I do is:

rxvt -e 'diff file1 file2;read'

I also notice that when I start fvwm, the window under the pointer is
not getting focused.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 21 Apr 2001 13:07:27 +0200

> rxvt -e 'diff file1 file2;read'

For me, that line just pops up and closes the rxvt immediately.
You can only run a single command with -e, sot a whole script.

> I also notice that when I start fvwm, the window under the pointer is

I do not get the core dump, but I may have different setup.  The
problem seems to be that the stack ring is corrupted between line
1323 and line 1438 in add_window.c.  A possible candidate may be
the SM code that modifies the stack ring.  Can you have a look,
Dan?

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 21 Apr 2001 12:59:18 +0200

> when the code works the other way?

Hm, I tried to debug this, but it does not happen for me.
Furthermore I noticed that my explanation of the problem can not
be correct.  When the window is mapped below the cursor it does
get a normal EnterNotify for me and thus receives focus.  Can you
provide the relevant config lines, please?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sat, 21 Apr 2001 11:08:32 -0400

> You can only run a single command with -e, sot a whole script.

I knew this wouldn't work, its just a placeholder until I write
the replacement.  Fortunately for us, it reveals an fvwm problem.

> the SM code that modifies the stack ring.  Can you have a look,

I'm looking.  I don't use session management, its not even compiled
in.

What happens is that the wire frame appears and then it core dumps.

It looks like  fvwm is  handling events with  the  wire frame visible.
Its trying to remove the window before its finished placing it.

Shouldn't the X server be grabbed while the wire frame is visible?

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 21 Apr 2001 09:12:20 -0500

> I also notice that when I start fvwm, the window under the pointer is

Maybe this is related, maybe not.
I got the same problem when I had one small ClickToFocus window which is
mapped on startups after the window under the pointer. To fix this I use:

  Style that_window ClickToFocus, GrabFocusOff  # the order matters

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sat, 21 Apr 2001 16:59:59 -0400

> the SM code that modifies the stack ring.  Can you have a look,

I see the problem, I've got to take a break so I'll look for a solution
later.

In placement.c around line 750 there is this:

      if (GrabEm(CRS_POSITION, GRAB_NORMAL))
      {
	/* Grabbed the pointer - continue */
	MyXGrabServer(dpy);
	if (XGetGeometry(dpy, tmp_win->w, &JunkRoot, &JunkX, &JunkY,
			 (unsigned int *)&DragWidth,
			 (unsigned int *)&DragHeight,
			 &JunkBW,  &JunkDepth) == 0)
        {
	  free((char *)tmp_win);
	  MyXUngrabServer(dpy);
	  return False;
	}
	MyXGrabKeyboard(dpy);
	DragWidth = tmp_win->frame_g.width;

The free is getting executed, so tmp_win  is gone, but subsequent code
still tries to add the window to the stack ring using that structure.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 22 Apr 2001 10:34:29 +0200

>   Style that_window ClickToFocus, GrabFocusOff  # the order matters

No, the problem appears without any ClickToFocus windows.  I have
fixed this by allowing one EnterNotify caused by XUngrabPointer to
be used right after startup.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 22 Apr 2001 10:43:32 +0200

> Shouldn't the X server be grabbed while the wire frame is visible?

Is is grabbed in add_window.c.  The event may have been generated
before the server was grabbed. 

The rxvt behaves a bit random for me.  Two thirds of the times it
vanishes right after mapping, the rest of the times it stays up.
Given the -e option it should always be closed.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 22 Apr 2001 11:13:32 +0200

> still tries to add the window to the stack ring using that structure.

I have removed the free() and cleaned up event handling in
moveLoop() a bit.  Although this may prevent the core dump for the
moment, it does not do anything about the disappearing window.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 22 Apr 2001 07:25:29 -0400

Dominik Vogt <[email-masked]> writes:
> > > > > > > I'm seeing a problem in the very latest CVS code (and for a week 
> or s
> > > o
> > > > > > > This is with rxvt's, but I have no reason to believe it wouldn't 
> happ
> > > en
> > > > > > > with other windows too.
> > > > > 

I tried removing the free, and  it left me  with a frame but no window
inside the frame.  I  just tested what  you committed, and it does the
same thing, except it worked right one time.  (The window appeared and
then disappeared.)  But more often, it leaves an empty frame around.
Theres a timing issue to this because add_window does an XGetGeometry
on the window that works, then the one in the placement logic fails.

When the placement logic  can't  find the  window anymore,  it  aborts
processing and returns false.  This eventually gets back to add_window
which sets the variable "do_resize_too"  to false.  I think it  should
be using that  false value as  a signal that the  window  is gone, not
just avoid  resizing it.   I'm   not sure what    else can cause   the
placement logic to return false yet.

---

From: Dan Espen <[email-masked]>
Date: Sun, 22 Apr 2001 19:07:06 -0400

> placement logic to return false yet.

This change:

2000-01-01  Dominik Vogt  <[email-masked]>
	* fvwm/placement.c (PlaceWindow):
	* fvwm/add_window.c (AddWindow):
	(setup_window_placement):
	signature of PlaceWindow() changed to return True or False only

changed the return code for PlaceWindow from a 3 value switch to
a true/false switch.

the comment at the top of PlaceWindow still says it returns 3 values
"ok", "ok w. resize" and "window lost".

The way AddWindow handles  the return code, I think  it still  wants 3
values, although our  current problem has to  do with it not  handling
"window lost".

I'm  not  sure what  it should  do either (when  the  window is lost).
Calling destroy_window doesn't seem to be any good.
Any hints?

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 23 Apr 2001 11:19:42 +0200

> Calling destroy_window doesn't seem to be any good.

What I don't understand: how can the window disappear so that fvwm
does not notice?  The MyXGrabServer() call in AddWindow() should
prevent that the window disappears without notice:

  /****** Make sure the client window still exists.  We don't want to leave an
   * orphan frame window if it doesn't.  Since we now have the server
   * grabbed, the window can't disappear later without having been
   * reparented, so we'll get a DestroyNotify for it.  We won't have
   * gotten one for anything up to here, however. ******/

The DestroyNotify should be caught by SubstructureRedirectMask on
the root window, but apparently it isn't.  Maybe if the window
dies before the call to XReparentWindow()?  Then we could add
another check with XGetGeometry() after the XReparentWindow()
call.  If it fails, we still run to the end of the function but
then destroy the window.

Perhaps it would be helpful to add debug output all over the code
to see at which moment the window dies.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Mon, 23 Apr 2001 05:55:18 -0400

> to see at which moment the window dies.

With the addition of the code I just added, it seems to be working
now.  I should have thought of letting addwindow finish the add
before trying to destroy the window.  I guess the half added window
was causing problems.

There is still the issue of the bad comments in the placement code
for the return type.
Also the prototype for PlaceWindow has the return type of int, vs
the bool in the code.