keyboard focus troubles on Alt+Tab window switch

[totaam]

Issue migrated from trac ticket # 214

component: core | priority: minor | resolution: worksforme

2012-11-14 16:06:24: onlyjob created the issue

---

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:

• switch to browser (Alt+Tab) and press 'down' arrow.
  Note the expected scroll.

• switch to editor (Alt+Tab)

• switch to browser (Alt+Tab)

• switch back to editor (Alt+Tab) and press 'down' arrow key.
  Note where scrolling occurs.

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.

[totaam]

2013-02-11 16:32:39: antoine changed status from new to accepted

[totaam]

2013-02-11 16:32:39: antoine commented

---

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

[totaam]

2013-04-23 19:42:21: afarr commented

---

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?

[totaam]

2013-06-23 16:24:09: antoine commented

---

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.

[totaam]

2013-06-25 05:37:05: antoine changed status from accepted to new

[totaam]

2013-06-25 05:37:05: antoine commented

---

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)

[totaam]

2013-06-25 05:37:19: antoine changed owner from antoine to onlyjob

[totaam]

2013-06-30 09:59:25: antoine changed status from new to assigned

[totaam]

2013-06-30 09:59:25: antoine changed owner from onlyjob to antoine

[totaam]

2013-06-30 09:59:25: antoine commented

---

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...

[totaam]

2013-07-02 15:46:46: antoine uploaded file debug-focus.patch (4.0 KiB)

enables extra focus debugging

[totaam]

2013-07-02 15:57:39: antoine changed status from assigned to new

[totaam]

2013-07-02 15:57:39: antoine changed owner from antoine to afarr

[totaam]

2013-07-02 15:57:39: antoine commented

---

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
[[BR]]

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)

[totaam]

2013-07-02 20:17:27: afarr commented

---

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?).

[totaam]

2013-07-05 07:26:29: antoine commented

---

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

[totaam]

2013-07-05 07:32:25: antoine commented

---

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

[totaam]

2013-07-05 20:07:50: afarr commented

---

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.

[totaam]

2013-07-13 16:01:46: antoine commented

---

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..

[totaam]

2013-09-27 00:01:47: afarr commented

---

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.

[totaam]

2013-09-27 02:57:43: totaam commented

---

re comment:13 - I believe this is a new and possibly different issue, probably caused by the fix for #412: 4312. 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.

[totaam]

2013-10-17 08:49:28: totaam changed status from new to assigned

[totaam]

2013-10-17 08:49:28: totaam changed owner from afarr to totaam

[totaam]

2013-10-17 08:49:28: totaam commented

---

focus and keyboard due for 0.12

[totaam]

2013-10-22 14:11:50: onlyjob commented

---

Replying to [comment:9 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...

[totaam]

2014-02-13 14:48:00: antoine commented

---

I've added focus debugging in r5444, see #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.

[totaam]

2014-02-14 21:51:19: maxmylyn commented

---

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.

[totaam]

2014-02-14 22:12:54: maxmylyn uploaded file xpra debug focus lazarus server.txt (20.8 KiB)

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

[totaam]

2014-02-14 22:14:06: maxmylyn uploaded file xpra debug focus lazarus windows.txt (7.7 KiB)

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.

[totaam]

2014-02-14 22:41:45: afarr commented

---

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.

[totaam]

2014-03-03 15:12:15: totaam changed status from assigned to new

[totaam]

2014-03-03 15:12:15: totaam changed owner from totaam to onlyjob

[totaam]

2014-03-03 15:12:15: totaam commented

---

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

[totaam]

2014-03-19 07:11:55: totaam changed status from new to closed

[totaam]

2014-03-19 07:11:55: totaam changed resolution from ** to worksforme

[totaam]

2014-03-19 07:11:55: totaam commented

---

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