Focus issue on creation of a new window

[GoogleCodeExporter]

A few things are happening here, and I do not know if they are related, but
they might be.

If i am in stack mode, when I create a chat window in Pidgin by double
clicking a contact.. the window is created and focus is implicitly passed
to that chat window, as it should be...
then if i switch back to the buddy list window after doing this, the
contact node that I had double clicked acts as if I am holding the mouse
button down on it, when i am not at all, that is, I can drag it all around
the screen by just moving the mouse.. until I click again

When I went to see what I could find out about this behavior, I tried wmiir
read /event and noticed that when in stack mode, it produces a duplicate
clientfocus event while changing focus in stack mode, that may be
completely irrelevant, but I figured it was worth mentioning since it was
unexpected behavior

I have attached a screencap video that illustrates both of these behaviors,
hopefully it will serve as a good summary.

Hopefully this is a relatively simple issue, If any more details are
required, I would be happy to provide them.

Original issue reported on code.google.com by adkilgore on 17 May 2010 at 10:11

Attachments:

• screencap.avi

[GoogleCodeExporter]

I'm not sure about the duplicate ClientFocus events (although I suspect that 
they're
generated by mouse grabs), but I think the Pidgin bug is, well, a Pidgin bug. 
When
the new window opens in stack mode, the new window probably opens before the 
contact
window receives the ButtonRelease event, so it goes to the chat window rather 
than
the contact window. GTK or Pidgin should probably handle that eventuality, but 
it
appears not to, whether because it gets iconified first or it just doesn't 
bother.
There's nothing wmii can do about it.

I'll look into the ClientFocus issue.

Original comment by maglion...@gmail.com on 18 May 2010 at 12:23

[GoogleCodeExporter]

Ah, that makes sense, thanks.

Original comment by adkilgore on 18 May 2010 at 12:38

[GoogleCodeExporter]

One reason that I reported it here was that I am still unable to reproduce the 
result
while using other window managers, the only other one I tried was icewm, but it 
does
not seem to happen there, and I am still trying to reason out why that would 
be. The
chat window seems to open up fast and the focus is redirected in a similar 
manner.

Original comment by adkilgore on 18 May 2010 at 1:16

[GoogleCodeExporter]

Another thing about this that I thought was strange, is that it only happens 
when one
is in stack mode, max mode does not produce the same result for me. If this 
were a
pidgin issue, I would think that it would manifest itself in either situation, 
as
well as in DWM and other window managers.

Original comment by adkilgore on 18 May 2010 at 1:57

[GoogleCodeExporter]

The focus is redirected fast, sure, but the contact list window is still under 
the
mouse pointer to receive the ButtonRelease. It wouldn't happen with wmii in 
floating
mode.

Original comment by maglion...@gmail.com on 18 May 2010 at 6:47

[GoogleCodeExporter]

Ah, thank you for your explanation, well, I am also able to reproduce this in 
max
mode, contrary to what I stated before, but the one last question I had about 
it is
that DWM has a mode where you can view one window at a time, sort of like max 
mode in
wmii, i guess, you can enter it with alt+M, and I tried that and cannot seem to
reproduce this problem there, is there a possible explanation for that?
Also, thank you Kris for all of the fast responses and the work you have done 
on wmii.

Original comment by adkilgore on 18 May 2010 at 10:00

[GoogleCodeExporter]

I've tested this, and I think the issue, in Pidgin's case, is the window being
unmapped before the last ButtonRelease event is received. When it's simply
obstructed, but not unmapped, it doesn't happen. dwm never unmaps windows, which
would explain why it doesn't happen there.

Original comment by maglion...@gmail.com on 22 May 2010 at 2:42

[GoogleCodeExporter]

This issue was closed by revision f9c228ff08.

Original comment by maglion...@gmail.com on 22 May 2010 at 2:52

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for all of the help. With all of this said, I guess the underlying issue 
is
with either Pidgin or GTK then?

I had reported this bug to the Pidgin folks earlier, hopefully they will be 
able to
come up with something (nothing yet, though) here is the ticket, in case anyone 
is
interested, I pointed them here, as well
http://developer.pidgin.im/ticket/11942

Original comment by adkilgore on 22 May 2010 at 3:17

[GoogleCodeExporter]

I found another way to reproduce this in another GTK application, in Firefox, 
you can
reproduce it by holding down the scroll button with the mouse, and at the same 
time,
make some popup window open (however you want to do that, for me, I got an IM, 
but
you can just press mod+enter to open an xterm), so that it covers firefox, when 
you
switch back to firefox, it never gets the mouse release event. Does this 
indicate
that this sort of thing is something that should be handled in GTK?

Original comment by adkilgore on 5 Jun 2010 at 9:51

[GoogleCodeExporter]

Also, If i were to report this on the GTK tracker, is a good way to summarize 
this
issue, that "mouse release events are not received when gtk windows are unmapped
during a mouse event"?

Original comment by adkilgore on 5 Jun 2010 at 10:20

[GoogleCodeExporter]

As you can see, this issue did not get any attention on the Pidgin bug tracker, 
probably because its a bit of an odd one. I was wondering why wmii unmaps 
windows when it switches between them in a stack. If I am analyzing this 
correctly, this behavior breaks some other random things like apps dealing with 
minimization to the tray. Take, for example, the FireTray addon, which detects 
a "minimization" when you switch away from the app in stack mode. Is there a 
reason that wmii does this? 

Original comment by adkilgore on 17 Feb 2011 at 3:58

[GoogleCodeExporter]

I posted a patch that I wrote that seems to fix and/or work around the Pidgin 
issue on the ticket in case anyone is interested.
http://developer.pidgin.im/ticket/11942

Original comment by adkilgore on 3 Apr 2011 at 11:27