xpra icon
Bug tracker and wiki

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#51 closed defect (fixed)

new window keyboard focus problem

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 0.0.7.x
Component: client Version: 0.0.7.32
Keywords: Cc: troycauble@…, rainwoodman@…

Description

This was originally recorded as #150 on winswitch bug tracker (see there for details), so I forgot about it..
This bug is getting annoying, let's try to fix it.

Attachments (1)

xpra-debug-focus.patch (18.0 KB) - added by Antoine Martin 8 years ago.
patch to make it easier to debug focus problems by printing all focus debug only

Download all attachments as: .zip

Change History (9)

comment:1 Changed 8 years ago by Antoine Martin

Cc: troycauble@… rainwoodman@… added
Owner: changed from Antoine Martin to Antoine Martin
Status: newaccepted

comment:2 Changed 8 years ago by Antoine Martin

Can reproduce it easily on win32 (and probably osx) by first connecting then starting a new terminal. On linux, the new window correctly gets focus, on win32 it does not...

comment:3 Changed 8 years ago by Antoine Martin

Found the problem, on win32 and osx (more often than on linux - but still not that often, even harder to trigger with the added delays introduced by debugging..) we get the focus update before the window is mapped, and the call to XSetInputFocus fails with BadMatch...
Sequence of the network packets in this case:

got ['focus', '15', '[]']
...
got ['map-window', '15', '114', '175', '744', '456']
Last edited 8 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 8 years ago by Antoine Martin

This particular problem is fixed in r357 by waiting for the window to get mapped before firing the focus_change method.
Problem is that there is still an issue when a second window pops up:

  • start server
  • connect client
  • launch first terminal (ok)
  • launch second terminal (does not get focus..)
    1323281101.14   update_focus(1,True) _focused=None
    1323281101.14   update_focus(1,True) _focused=1
    1323281102.17   update_focus(1,False) _focused=1
    1323281103.05   update_focus(2,False) _focused=None
    

For some reason, gtk sets has-toplevel-focus to False for this one, so the focus never happens... and we don't seem to get notified either!?

comment:5 Changed 8 years ago by Antoine Martin

There are more focus problems lurking:

  • start server
  • connect with client
  • start terminal window1
  • start terminal window2
  • focus 1
  • focus away (any non-xpra window)
  • focus 2
  • type ^D
  • focus 1, the window then receives "ddddd" characters...

What I think is happening: the 'd' key is released when no xpra window has the focus (the focus should be on the root window in the server) and it is only when we focus 1 again that the keys get delivered.

comment:6 Changed 8 years ago by Rainwoodman

Apparently keyevents are grabbed on the client per window, but delivered to the server globally.

Changed 8 years ago by Antoine Martin

Attachment: xpra-debug-focus.patch added

patch to make it easier to debug focus problems by printing all focus debug only

comment:7 Changed 8 years ago by Antoine Martin

Resolution: fixed
Status: acceptedclosed

r369 ensures that we correctly unfocus windows when they are unmapped or destroyed.
This fixes the bug described in comment:5.

This is all done client side and I think we probably ought to detect when the "world_window" gets the focus (server-side) and do something similar there. (clear keys, etc)
But this will do for now...

comment:8 Changed 8 years ago by Antoine Martin

Milestone: current0.0.7.x
Version: 0.0.7.32
Note: See TracTickets for help on using tickets.