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. :)
not sure how to deal with this one, re-scheduling
Is there a specific client or server that was causing this? Maybe one of the numerous patches inadvertantly solved this issue too?
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.
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)
enables extra focus debugging
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)
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)
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?).
afarr: which text editor? (works ok with gedit here)
I've reverted the OR hack in r3768 - and may yet revert some more OR focus related changes..
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.
I'll have to look at this again, but maybe after 0.10..
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.
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.
focus and keyboard due for 0.12
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...
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.
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.
lazarus focus testing: login to gmail, compose email, alt-tab out, and back in; focus goes to address bar
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.
Testing with osx 10.9 r5444 generates same behavior as with windows 7 client.
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.
With trunk, I am completely unable to get focus problems with
xterms, can we close this as fixed?
Not heard back, assuming this is fixed, please re-open if not.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/214