Xpra: Ticket #214: keyboard focus troubles on Alt+Tab window switch

Here is a little but pesky problem with Xpra:

In Xpra session, open editor application (with sample document), then web browser (with any long page for scrolling). Ideally (but not necessary) for ease of demonstration both applications are to be positioned with partial overlap or next to each other.

Note the cursor position in editor. Now let's switch between browser and editor and see where keyboard focus will be:

The above sequence may be repeated from 1 to 6 times to reproduce the issue:

occasionally after switching back to editor its window raises but key presses go to previous application that was active before last Alt+Tab.

In the end of the sequence of this example, scrolling expected to happen in editor. However typing goes to browser despite visually correct window behaviour. This issue can only be noticed by the absence of text cursor in entry field of the raised application. Originally I thought it somehow depends on where I left the mouse cursor but it doesn't matter. From what I can see it happens in all applications which is quickly becomes annoying when editing requires repetitive copy-paste operations between applications and therefore many Alt+Tab switches.

Apparently all 0.7.x versions are affected.

I hope this can be helped. :)

Thank you.



Mon, 11 Feb 2013 16:32:39 GMT - Antoine Martin: status, milestone changed

not sure how to deal with this one, re-scheduling


Tue, 23 Apr 2013 18:42:20 GMT - alas:

Testing with windows client r3128 and fedora server r3128 (with Firefox & a nano editer through xpra xterms) I can't reproduce this behavior.

Is there a specific client or server that was causing this? Maybe one of the numerous patches inadvertantly solved this issue too?


Sun, 23 Jun 2013 15:24:09 GMT - Antoine Martin:

Since this is a race, does this patch make any difference?

--- src/xpra/x11/server.py	(revision 3696)
+++ src/xpra/x11/server.py	(working copy)
@@ -422,9 +422,7 @@
             window = self._id_to_window.get(wid)
             if not window:
                 return reset_focus()
-            #no idea why we can't call this straight away!
-            #but with win32 clients, it would often fail!???
-            gobject.idle_add(window.give_client_focus)
+            window.give_client_focus()
             if server_source and modifiers is not None:
                 server_source.make_keymask_match(modifiers)
             self._has_focus = wid

As per the comment inline, it was needed before for win32 clients. If it helps, it will require thorough testing on win32 to make sure this doesn't cause any regressions.


Tue, 25 Jun 2013 04:37:04 GMT - Antoine Martin: status changed

The change from comment:3 has been merged as part of r3713

Since there were some changes in this area, would you mind checking to see if it has made things better or worse? (or just unchanged)


Tue, 25 Jun 2013 04:37:19 GMT - Antoine Martin: owner changed


Sun, 30 Jun 2013 08:59:25 GMT - Antoine Martin: owner, status changed

Somewhere between r3713 and r3737, I've made thing worse: simply alt-tabbing to and from an xterm is enough to eventually lose the focus on the xterm when we should have it...


Tue, 02 Jul 2013 14:46:46 GMT - Antoine Martin: attachment set

enables extra focus debugging


Tue, 02 Jul 2013 14:57:39 GMT - Antoine Martin: owner, status changed

well then, I've just tried again and I cannot reproduce the alt-tab focus problems on linux with an xterm. (and I don't have the win32 vm at hand)

See also #356, #336

Can you please help me figure out if this is still and issue, on which platforms, with which versions (at this point, we only care about v0.9.x if we have caused a regression), with which applications (ensight on win32?), etc.. (if needed, please apply the patch in this ticket to get useful debugging information in both client output and server log)


Tue, 02 Jul 2013 19:17:26 GMT - alas:

From what I can tell, with 0.9.6 win client and 0.9.6 fedora server, the only thing even mildly annoying when using alt-tab to switch between a text editor app and a browser (in this case a google doc text editor cloud app) was that, if I switch focus while the cursor is on a blank line, then when I switch focus back the cursor doesn't "remember" where it was horizontally on the previous full lines- so instead of "hopping back" to the 10th character from the left (for example) it will instead scroll up or down at the left margin.

I can't imagine considering this to be still an issue (unless the steps in the original ticket to reproduce aren't sufficient to reproduce the issue currently?).


Fri, 05 Jul 2013 06:26:28 GMT - Antoine Martin:

afarr: which text editor? (works ok with gedit here)


Fri, 05 Jul 2013 06:32:24 GMT - Antoine Martin:

I've reverted the OR hack in r3768 - and may yet revert some more OR focus related changes..


Fri, 05 Jul 2013 19:07:49 GMT - alas:

I was using a gedit started in an xpra xterm, and I was alt-tabbing to switch to a google doc opened in a local chrome browser tab- which was the only way I could tell exactly where the cursor was on both sides. Using long scrollable, but not writable, pages in the local browser the cursor would "disappear", though the down arrow keys would still scroll fine.

The gedit cursor behaved the same no matter what the other window I was switching focus to was. If on a blank line, then once focus was re-established it would scroll up/down at the left margin, if indented on a line with text it would maintain that same horizontal distance from the margin when arrowing up or down exactly as expected.


Sat, 13 Jul 2013 15:01:45 GMT - Antoine Martin:

with r3846, we should be back to what we had before r3713. Not great, but better than the mess I generated with those changes.

I'll have to look at this again, but maybe after 0.10..


Thu, 26 Sep 2013 23:01:46 GMT - alas:

Found another instance of this alt-tab focus issue, with the lazarus browser specifically.

Open some editor inside the xpra session, an email composition page for example.

Type something into the composition field

alt-tab to another window, then alt-tab back.

The focus in the composition field is lost.

Interestingly, with a fedora server using 0.10.1 r4275, when user alt-tabs back to the window the focus shifts to the address bar (using win client 0.11.0 r4309 or 0.10.4 r3421 the behavior is the same).

Meanwhile, using a fedora server running 0.10.4 r4321 and going through the same steps, the focus is lost entirely until the mouse is used to re-fix it somewhere (using win clients 0.11.0 r4309 or 0.10.4 r4321 the behavior is again the same).

Not sure if this bit of information is food for any thought, but it seems to suggest that this is more of a server issue than a client issue.


Fri, 27 Sep 2013 01:57:43 GMT - Antoine Martin:

re comment:13 - I believe this is a new and possibly different issue, probably caused by the fix for #412: r4312. Please confirm by unapplying this patch on top of v0.10.4 to see if the issue persists.

I believe that what is happening is that we used to unpress all modifiers (by accident) and the changeset fixes that (which fixes "Shift") but it also means that "Alt" is being held for a long time (until xpra regains top level focus) which probably causes the application (or its toolkit) to take action (move focus somewhere). I can't think of a good fix... only really ugly ones.


Thu, 17 Oct 2013 07:49:28 GMT - Antoine Martin: owner, status, milestone changed

focus and keyboard due for 0.12


Tue, 22 Oct 2013 13:11:49 GMT - onlyjob:

Replying to antoine:

afarr: which text editor? (works ok with gedit here)

Sorry, in retrospect I think I didn't mention text editor because it was happening in all of them... I was using geany, kate and emacs.

Very often pressing Alt-Tab switch to application where typing is impossible (no cursor and no key presses received by application) until Alt-Tab is pressed couple more times to bring application to focus once again. This is happening with any (all) applications that use keyboard...


Thu, 13 Feb 2014 14:48:00 GMT - Antoine Martin:

I've added focus debugging in r5444, see ticket:469#comment:2 for details.

Posting logs of the problematic switching, comparing those with the working switching logs should tells us where the problem lies, I hope. I have seen the problem, but not often, so feel free to beat me to it.


Fri, 14 Feb 2014 21:51:19 GMT - J. Max Mena:

Retested with r5444 Win7.

Testing with gedit: Alt-tabbing out(to local text editor), and back in(gedit on server), cursor goes back to where it was before alt-tabbing out

Testing with lazarus browser: Using Gmail compose, alt-tabbing out(to local text editor), and back in(lazarus browser), the cursor defaults to the address bar as seen in comment:13

I will attach some logs to this ticket.


Fri, 14 Feb 2014 22:12:53 GMT - J. Max Mena: attachment set

lazarus focus testing: login to gmail, compose email, alt-tab out, and back in; focus goes to address bar


Fri, 14 Feb 2014 22:14:05 GMT - J. Max Mena: attachment set

lazarus focus testing: login to gmail, compose email, alt-tab out, and back in; focus goes to address bar these are the outputs from the windows client. The other .txt is the output from the server.


Fri, 14 Feb 2014 22:41:45 GMT - alas:

Testing with osx 10.9 r5444 generates same behavior as with windows 7 client.

Using gedit and alt-tabbing to other applications, then back to gedit keyboard focus is as expected (same character as before alt-tabbing, arrow keys behave as expected).

Using lazarus browser behaves as with windows 7 client as well (using a gmail email composition page, alt-tabbing to other applications, then alt-tabbing back the focus shifts from the composition buffer to the left edge of the address bar... moving the focus to the middle of the address bar then alt-tabbing away and back brings focus, again, to the left edge of the address bar).

With a chrome gmail composition page, however, the focus after multiple alt-tabbings behaves as expected... so it seems likely to be a lazarus focus issue rather than xpra. In any case, the server and client -d focus output looks the same for osx as for windows.


Mon, 03 Mar 2014 15:12:15 GMT - Antoine Martin: owner, status changed

With trunk, I am completely unable to get focus problems with xterms, can we close this as fixed?


Wed, 19 Mar 2014 07:11:55 GMT - Antoine Martin: status changed; resolution set

Not heard back, assuming this is fixed, please re-open if not.


Sat, 23 Jan 2021 04:48:37 GMT - migration script:

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