Subject: FVWM: Mysterious RaiseOverNativeWindows bug [was: New problems since 2. 3.6]

From: "Adye, TJ (Tim) " <[email-masked]>
Date: Fri, 18 May 2001 01:50:57 +0100

Hi Dominik,

I've adjusted the subject line to distinguish my remaining problem (thanks
to you and others on this list, of the other two, one has been fixed and I
have a patch for the other). The following tests are all with a local
fvwm-snap-20010510, built under Cygwin 1.3.1 on Windows 2000, and Exceed
6.2.0.16 as X-server.

On 01 May 2001, I wrote:
>
> 1) I use ClickToFocus. This mostly works correctly with X and 
> native windows together, but if the active X-window is behind 
> a native window, it is raised if the cursor moves over it 
> [...]. I tried turning on BugOpts 
> RaiseOverNativeWindows, but this doesn't seem to make any 
> difference (I guess it's switched on automatically). As one 
> might expect, turning it off prevents X-windows being raised 
> over the native window at all (even by a click).

and on 06 May 2001, Dominik Vogt <[email-masked]> wrote:
>
> I searched up and down the code but I can't find any way how
> simply moving the pointer over the focused window could trigger
> raising or lowering windows.  You said that turning of the
> RaiseOverNativeWindows option 'fixes' the problem.  This proves
> that the RaiseOrLowerWindow() function is called when the pointer
> enters the window because it is the only place where the option is
> evaluated.  But fvwm does not call this function.

I added debug messages to RaiseOrLowerWindow() and confirmed that it is not
called when I get this mysterious "autoraise". I have however found some
more clues that might help track down the cause of this problem.

First, I have found some option settings that seem to "cure" the autoraise
problem (but in other respects aren't much to my liking). I also narrowed
down my .fvwm2rc to the simplest that demonstrates it. With just the
following .fvwm2rc (and nothing else), I get the autoraise problem:-

  Style * ClickToFocus
  BugOpts RaiseOverNativeWindows
  EdgeScroll 0 0
  EdgeThickness 0
  DeskTopSize 1x1

However if I comment out (or explicitly set default values for) the
EdgeScroll, EdgeThickness, and DeskTopSize lines, the problem goes away. If
*any* of the above settings is restored, then the problem returns. This is
very curious, as the connection between window raising and the desktop size
/ scrolling functions seems obscure.

Unfortunately, even with those lines removed, the behaviour still isn't
perfect (though much better). Now the active X-window isn't raised over a
native window, even when I click in it - I have to click on the title bar or
borders. Contrariwise, inactive X-windows are raised correctly if I click
inside the window.

Another observation: although most application windows (eg. FvwmForm, xterm,
emacs, rclock) show the autoraising problem, xlogo and xclock don't. What's
different about these guys? In particular, rclock and xclock seem pretty
similar, but the former shows the autoraise bug.

Finally, I had a look with Exceed's tracing facility. I'm not really
qualified to interpret the results, but I hope I've extracted the relevant
portion that someone else can understand. I append the results to this
message (please let me know if you want more detail).

Does any of this help diagnose the problem?

Thanks,
Tim.

==============================  cut here  ==============================

Extracts from Exceed trace logs
===============================

The format seems to be (taking the first line below as an example): packet
71, 648723 milliseconds from server start, socket 1, protocol request number
42, protocol request name SetInputFocus. This is followed by the request
parameters.

This first sequence occurred when I moved the mouse from a native (Notepad)
window over to an active X-window (xterm) which partially concealed behind
it. The xterm window was (incorrectly) raised (and received input focus).

71: [648723.340] (1) --> Request 42 SetInputFocus

revert to         Parent
focus             0x100000e
time              CurrentTime

73: [648723.0] (1) <-- Event 9 FocusIn

sequence #        0x52e2
detail            NonLinear
event             0x100000e
mode              Normal

77: [648743.20] (1) <-- Event 12 Expose

sequence #        0x52e2
window            0x4000d6
xy                [225, 0]
width x height    403 x 7
count             2

77: [648743.0] (1) <-- Event 12 Expose

sequence #        0x52e2
window            0x4000d6
xy                [621, 7]
width x height    7 x 160
count             1

77: [648743.0] (1) <-- Event 12 Expose

sequence #        0x52e2
window            0x4000d6
xy                [225, 167]
width x height    403 x 7
count             0

78: [648743.0] (1) <-- Event 12 Expose

sequence #        0x52e2
window            0x4000e0
xy                [218, 0]
width x height    396 x 16
count             0

80: [648753.10] (4) --> Request 76 ImageText8

drawable          0x1000015
gc                0x1000018
xy                [37, 17]
text              " "

... followed by lots more.

Next, I did the same, but this time with an inactive xterm window, also
behind the native window. The only result was:-

295: [686548.160] (1) <-- Event 18 UnmapNotify

sequence #        0x5313
event             0x2a
window            0x42
from configure    false

297: [686548.0] (1) <-- Event 7 EnterNotify

sequence #        0x5313
detail            NonLinearVertical
time              686548
root              0x2a
event             0x80000e
child             0x800015
root xy           [437, 600]
event xy          [406, 121]
state             0
mode              Normal
focus             false
same screen       true

Finally, I clicked on the inactive xterm window, bringing it to the front.

560: [215050.541] (3) <-- Event 9 FocusIn

sequence #        0x9f
detail            Pointer
event             0xc0000e
mode              Normal

561: [215050.0] (1) <-- Event 9 FocusIn

sequence #        0x18af
detail            Pointer
event             0xc0000e
mode              Normal

563: [215070.20] (3) --> Request 76 ImageText8

drawable          0xc00015
gc                0xc00018
xy                [37, 17]
text              " "

565: [215150.80] (3) <-- Event 8 LeaveNotify

sequence #        0xa0
detail            Virtual
time              215150
root              0x2a
event             0xc0000e
child             0xc00015
root xy           [180, 780]
event xy          [164, 133]
state             Button1
mode              Grab
focus             true
same screen       true

... followed by lots more.

==============================  cut here  ==============================
Tim Adye, BaBar/DELPHI Groups, Particle Physics Dept.,     _   /|
          Rutherford Appleton Laboratory, UK.              \'o.O'   Oop!
e-mail:   [email-masked] or VXCERN::ADYE (HEPNET/SPAN)  =(___)=  Ack!
WWW:      http://hepwww.rl.ac.uk/Delphi/Adye/homepage.html    U  Thphft!
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 May 2001 22:38:53 +0200

> more clues that might help track down the cause of this problem.

You must have made some mistake.  If the function were not called
then turning off

  BugOpts RaiseOverNativeWindows off

would not have "fixed" your problem.  What I wanted to say was
that fvwm does not call the function on its own when the pointer
enters a window (or receives focus).

> / scrolling functions seems obscure.

The problem seems to be related to the "pan frame" windows, small
invisible windows that surround the viewport that are used for
page scrolling.  It seems that your problem occurs only if there
are no pan frame windows.  The corresponding code in
checkPanFrames() was a bit confusing, so I rewrote it partially.
The pan frame windows are raised from several places throughout
the code to make sure they are on top of everything else - even
above native windows.  So this is the relation to your problem.

> borders. Contrariwise, inactive X-windows are raised correctly if I click

It seems that fvwm thinks these windows are already on top and do
not need to be raised when clicked anymore.  I think I have fixed
this one.

> similar, but the former shows the autoraise bug.

xclock and xlogo do not accept the keyboard focus therefore they
can never be focused, and since only the focused window shows the
problem, they don't.  Try

  Style xclock Lenience

and you will see the same problem for xclock.

> Extracts from Exceed trace logs

Um, didn't you say that the X window already had the focus?  Does
this mean that Exceed takes away the keyboard focus from the X
window as soon as the pointer moved over a native window?  Even
with ClickToFocus?  Perhaps there is some kind of auto raising
under windows.  Doesn't it bring a window to the front as soon as
it receives focus?

> 71: [648723.340] (1) --> Request 42 SetInputFocus
...

Hm, wasn't there any EnterNotify or ConfigureRequest?  Okay, it
seems that focusing the window triggers the problem somehow

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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].