xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 10 years ago

Closed 10 years ago

Last modified 12 months 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:
Keywords: Cc: troycauble@…, rainwoodman@…


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 10 years ago.
patch to make it easier to debug focus problems by printing all focus debug only

Download all attachments as: .zip

Change History (10)

comment:1 Changed 10 years ago by Antoine Martin

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

comment:2 Changed 10 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 10 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 10 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 10 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 10 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 10 years ago by Rainwoodman

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

Changed 10 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 10 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 10 years ago by Antoine Martin

Milestone: current0.0.7.x

comment:9 Changed 12 months ago by migration script

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/51

Note: See TracTickets for help on using tickets.