GNOME Bugzilla – Bug 102209
clicking on window causes leave/enter events
Last modified: 2004-12-22 21:47:04 UTC
I made a small test program. With metacity, when I click on the window, I receive the following events: ** Message: leave_notify_event ** Message: enter_notify_event ** Message: button_press_event ** Message: ----------- In contrast, with other window managers (I tested with fvwm2), I get this: ** Message: button_press_event ** Message: ----------- The extra leave/enter events are crippling a program I'm working on. Can't this be fixed?
Created attachment 13272 [details] A small gtk test program
*** Bug 98233 has been marked as a duplicate of this bug. ***
This is still the same I assume?
I checked in a fix that should work, give it a try.
*** Bug 114625 has been marked as a duplicate of this bug. ***
This fix seems to have made it so that windows don't raise any more on click, unless it's a frame click. Was this intended?
Was not intended, but on the other hand it works for me. I guess in sloppy focus you can focus a window without raising it and then you'd have that problem. I was thinking of changing back to no-raise-on-click in mouse focus mode anyway, coincidentally. Though this is kind of an odd way to implement that. I guess the way to fix the problem would be to select for button press events, but don't do the XGrabButton. Anyhow let's open a new bug for that.
what's the new bug? I upgraded to gnome 2.3.3 from 2.2.2, and windows became very difficult to raise (I'm using sloppy focus). Actually, a raise on doubleclick would make me happiest, but I'd gladly take back the old functionality. Looking for the frame to raise windows makes sloppy focus nearly useless.
Hmm. I realized I'm being inconsistent, having asked for pretty much the opposite earlier. The power of habit, or something.
this bug is back in sloppy and mouse focus, but unfortunately we can't fix it. Workaround is to use click-to-focus. Long-term the X protocol should be changed to allow this to be fixed properly.
if ((GdkEventCrossing *) event->mode == GDK_CROSSING_NORMAL) { /* Do whatever you want to do when the pointer * really enters or leaves the window. */ } else { /* Don't do it. */ }
I find it strange that this is a problem with X protocol, considering that other window manager don't show this problem at all.
If you know another WM without this problem in the case of: mouse/sloppy focus, and *raising on click of the window client area*, then please let us know which WM that is and we'll look at how it does it.
As I mentioned at the top of this report, I tested fvwm2 and it works well. I just don't exactly remember if fvwm2 uses "sloppy focs" or "focus follows mouse" by default. I tested now Window Maker (0.80.1) with "sloppy focus", and it also works fine. To tell the truth, now I'm using metacity with "click to focus" :P But still this could lead to buggy behaviour in some applications when used with metacity in "sloppy focus" mode. Not to mention the additional processing required by some canvas systems that change state of objects on enter/leave notify, for example.
Damn C syntax; parentheses are needed around the cast and `event'. if (((GdkEventCrossing *) event)->mode == GDK_CROSSING_NORMAL) { ... etc.
The problem with simply ignoring enter/leave caused by a grab is that the mouse can move during the grab, and grabs can be caused by lots of clients in lots of situations. So if you ignore these events you can also get bugs where the wrong window is focused.
Ignoring the grab crossings is for applications, not the window manager. However, indeed it semes the grab/ungrab crossings can't just be ignored for what Mozilla is trying to do - they need the real `mouseout'. There's at least one other way for mozilla to get the `mouseout'. When it needs to know where the pointer is, it can query the pointer. Xeyes does this and so it is able to update regardless of grabs. Of course, Mozilla, unlike Xeyes, should not query the pointer all of the time. In other words, the resolution of this bug is correct. The problem is not GNOME's. It's not even X's.