xpra icon
Bug tracker and wiki

Opened 8 years ago

Closed 6 years ago

#214 closed defect (worksforme)

keyboard focus troubles on Alt+Tab window switch

Reported by: onlyjob Owned by: onlyjob
Priority: minor Milestone: 0.12
Component: core Version: 0.7.x
Keywords: Cc:

Description

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.

Attachments (3)

debug-focus.patch (4.0 KB) - added by Antoine Martin 7 years ago.
enables extra focus debugging
xpra debug focus lazarus server.txt (20.8 KB) - added by J. Max Mena 6 years ago.
lazarus focus testing: login to gmail, compose email, alt-tab out, and back in; focus goes to address bar
xpra debug focus lazarus windows.txt (7.7 KB) - added by J. Max Mena 6 years ago.
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.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 7 years ago by Antoine Martin

Milestone: 0.80.9
Status: newaccepted

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

comment:2 Changed 7 years ago by 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?

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by Antoine Martin

Status: acceptednew

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)

comment:5 Changed 7 years ago by Antoine Martin

Owner: changed from Antoine Martin to onlyjob

comment:6 Changed 7 years ago by Antoine Martin

Owner: changed from onlyjob to Antoine Martin
Status: newassigned

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

Changed 7 years ago by Antoine Martin

Attachment: debug-focus.patch added

enables extra focus debugging

comment:7 Changed 7 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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)

comment:8 Changed 7 years ago by 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?).

comment:9 Changed 7 years ago by Antoine Martin

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

comment:10 Changed 7 years ago by Antoine Martin

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

comment:11 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by 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..

comment:13 Changed 7 years ago by 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.

comment:14 Changed 7 years ago by 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.

comment:15 Changed 7 years ago by Antoine Martin

Milestone: 0.90.12
Owner: changed from alas to Antoine Martin
Status: newassigned

focus and keyboard due for 0.12

comment:16 in reply to:  9 Changed 7 years ago by 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...

comment:17 Changed 6 years ago by 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.

comment:18 Changed 6 years ago by 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.

Changed 6 years ago by J. Max Mena

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

Changed 6 years ago by J. Max Mena

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.

comment:19 Changed 6 years ago by 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.

comment:20 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to onlyjob
Status: assignednew

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

comment:21 Changed 6 years ago by Antoine Martin

Resolution: worksforme
Status: newclosed

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

Note: See TracTickets for help on using tickets.