18:14:06

Applied patches by Andreas, seems to be resolved in git head.

13:21:24

Decided to test if I can reproduce this, and I can, but...

It seems that you can get the input field to take focus if you keep clicking on it. Sometimes the whole window looses focus, sometimes it gets focus but still doesn't allow input, and then, if you are lucky, you get the window focused and accepting input.

I added a cerr to see what's happening in PWinObj::giveInputFocus():

 ...
 PWinObj.cc@235: PWinObj(0x1563710)::giveInputFocus()
  *** _window = 56623163
 PWinObj.cc@235: PWinObj(0x1481680)::giveInputFocus()
  *** _window = 315
 PWinObj.cc@235: PWinObj(0x1563710)::giveInputFocus()
  *** _window = 315
 ...

Here 56623163 is what I expect, while 315 isn't.

'xprop -root -spy' can't decide between the active window either (0x0 is obviously wrong):

 ...
 _NET_ACTIVE_WINDOW(WINDOW): window id # 0x360003b
 _NET_ACTIVE_WINDOW(WINDOW): window id # 0x0
 _NET_ACTIVE_WINDOW(WINDOW): window id # 0x0
 _NET_ACTIVE_WINDOW(WINDOW): window id # 0x0
 _NET_ACTIVE_WINDOW(WINDOW): window id # 0x360003b
 _NET_ACTIVE_WINDOW(WINDOW): window id # 0x0
 ...

While double clicking the input field (or just clicking fast) seems to increase my changes, it seems random when I actually get to input stuff.

A quick "fix" is to remove the default mouse binding for clicking on a client window:

 Client {
  ButtonPress = "1" { Actions = "Focus" }
 }

While we still go through the process of initial correct window id being reported when pointing the pointer at the window (and thus trickering one of the Enter focus actions defined in the mouse configuration), then window id going to 0x0 when clicking on the input field for the first time, we after that get the correct active window id and a constant input focus no matter how many additional times we click on the input field.

After removing the focus action, above results as this output from 'xprop -root -spy':

 _NET_ACTIVE_WINDOW(WINDOW): window id # 0x360003b
 _NET_ACTIVE_WINDOW(WINDOW): window id # 0x0
 _NET_ACTIVE_WINDOW(WINDOW): window id # 0x360003b

and from PWinObj::giveInputFocus():

 PWinObj.cc@235: PWinObj(0x1110730)::giveInputFocus()
  *** _window = 56623163
 PWinObj.cc@235: PWinObj(0x1054760)::giveInputFocus()
  *** _window = 315

I'm not sure how helpful these observations are, but there they are.

13:27:41

This looks like the same bug that compiz had, see https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/122654/comments/8

Here is the commit from compiz:

http://cgit.freedesktop.org/xorg/app/compiz/diff/?h=compiz-0.6&id=1c9237b8f824ba9902b9ffb50d279553f9d73220

10:16:31

I am able to reproduce by using the xvnc4viewer package in Ubuntu Hardy:

 VNC Viewer Free Edition 4.1.1 for X - built Apr 16 2008 13:02:40
 Copyright (C) 2002-2005 RealVNC Ltd.
 See http://www.realvnc.com for information on VNC.

To reproduce just start xvncviewer command and try to fill in something in the 'VNC Server' field.