Xpra: Ticket #366: cursor focus error created somewhere between r3680 and 3725 server revisions

This is a problem that only reveals itself with a lazarus build browser on youtube, with a server side xpra 0.10.0 (fedora 18) with a revision that I've narrowed to somewhere between 3680 and 3725.

With a 0.10.0 r3725 (or r3760) winClient (or anything before, presumably) the problem doesn't manifest with r3680 or before, but does with all servers r3725 and newer.

The problem is a cursor focus issue related specifically to the search bar of youtube with a lazarus browser. (I couldn't find it on any other pages or on youtube with firefox or chrome.)

If the mouse cursor hovers over the search bar, then the keyboard cursor jumps to the left margin of the address bar (somewhat reminiscent of the bug described in #214). Clicking the mouse on the search bar to change focus for the keyboard's cursor causes a cannot handle window transparency! error in the client cmd window. Once this is done, if the mouse cursor (arrow or whatever) is hovering over the search bar then one character can be typed into the search bar... after which the cursor focus for any further characters typed shifts to the left margin of the address bar. Clicking back on the search bar will only cause this process to repeat.

On the other hand, if a mouse click changes cursor focus for the keyboard to the address bar then typing behaves as expected— unless the mouse cursor is hovering over the search bar... in which case the cursor focus for the keyboard will, again, jump to the left margin of the address bar.

If the mouse cursor hovers over any other portion of the page, however, then the keyboard focus and typed characters behave as expected.

Tue, 02 Jul 2013 23:52:29 GMT - Antoine Martin: owner changed

Please post focus debug messages using the patch from #214

Wed, 03 Jul 2013 13:08:55 GMT - Antoine Martin:

see comment:1

The problematic commit is very likely to be r3713 - but we cannot just revert it without understanding why that is (as it fixes other problems with focus..)

It is also worth testing with a Linux client to see where this transparent window really is. Another way of finding that out is to record "xpra info" when this happens.

The cannot handle window transparency! error is due to the fact that GTK does not support window transparency on win32. It is harmless but I will try to improve things in 2 ways:

Wed, 03 Jul 2013 18:37:36 GMT - alas: attachment set

xpra info with mouse hovering over youtube searchbar

Wed, 03 Jul 2013 18:38:19 GMT - alas: attachment set

xpra info with mouse not hovering over youtube searchbar (over address bar)

Wed, 03 Jul 2013 18:38:58 GMT - alas: attachment set

xpra info with mouse over xterm showing as GIANT cursor

Wed, 03 Jul 2013 18:43:25 GMT - alas:

For now I've attached xpra info output files, one with the focus (before I switch to window to get xpra info) and mouse over the problematic search bar, and the other with the focus on the not-so-problematic search bar. I also included an attachment with the giant xterm cursor displayed, in case that might help with the side issue. I'll post again with focus debug output once I have a build with the patch.

Wed, 03 Jul 2013 20:51:46 GMT - alas: attachment set

copied output from server with focus debug patch

Wed, 03 Jul 2013 20:53:31 GMT - alas: attachment set

Another xpra info with youtube search bar in focus (using alt-tab to get to window to run xpra info)

Wed, 03 Jul 2013 20:55:09 GMT - alas: status changed

Also attached file of debug patch output (server side) and another xpra info dump captured with search bar in focus using alt-tab to reach window to run xpra info (in case that produces different/better results).

Thu, 04 Jul 2013 03:00:09 GMT - Antoine Martin:

Note: do not use alt-tab to run xpra info, this will ruin the focus state.

Either run it from another machine, or run it via a timer:

sleep 5; xpra info

Thu, 04 Jul 2013 04:59:36 GMT - Antoine Martin:

Trimming the logs for things of interest:


So it looks like a tooltip window is stealing the focus. Maybe I should revert the OR window focus completely, and handle grabs instead.

Note: the version you used is a little bit too old and is missing the cursor data (which belongs in another ticket anyway) as well the new focus information from "xpra info".

Thu, 04 Jul 2013 18:50:29 GMT - alas: attachment set

xpra info with focus in search bar (captured from different machine)

Thu, 04 Jul 2013 18:51:32 GMT - alas: attachment set

xpra info with focus in address bar (not search bar, captured with different machine)

Thu, 04 Jul 2013 18:59:32 GMT - alas:

Ok, used a different machine to capture xpra info - both with focus inside the misbehaving search bar and outside, arbitrarily on the behaving address bar. Two new attachments to peruse.

The focus-debug info hasn't changed though, of course.

Fri, 05 Jul 2013 07:31:50 GMT - Antoine Martin:

Tue, 09 Jul 2013 19:41:07 GMT - alas: attachment set

server debug and error logs from clicking into youtube search bar

Tue, 09 Jul 2013 20:00:58 GMT - alas:

With r3778 I no longer see the window transparency errors. The behavior in the youtube search bar, however, remains the same.

I've attached the server-side error and debug logs (r3778 on both sides), starting with the shift of focus that occurs when I click on the youtube search bar (with the focus having started on the server ssh shell, not the xpra session). It looks like it shifts focus and then does a reset_focus (which looks like it's an expected part of the process).... but then there's a traceback caused by some sort of "raw mode"... which leads to a focus shift to a OverrideRedirectWindowModel object - which seems likely to be where the shift to the address bar occurs.

(The final focus shift comes when I copy the logs from the server ssh.)

Hopefully this nails down our culprit.

Tue, 09 Jul 2013 20:21:55 GMT - alas: attachment set

Logs showing tracebacks with drop menus similar to those from focus issues

Tue, 09 Jul 2013 20:25:33 GMT - alas:

Also attaching some logs with the same unknown raw mode tracebacks, which were produced when clicking a button for a drop menu (of smilies, of all things).

Might be the focus and the drop menu bugs are related, might be a help pinning this one down.

Tue, 09 Jul 2013 21:34:55 GMT - alas:

Odd... the traceback error (& the cursor jumping intermittently) now seems to also be happening on facebook. In addition to the tracebacks and the focus shifting logs, I spotted one other unique nugget:

ValueError: unknown raw mode
21:39,644 _focus(ServerSource(Protocol(SocketConnection(('', 1200) - ('', 55929)))), 6, ('mod2',)) \
21:39,644 focus(ServerSource(Protocol(SocketConnection(('', 1200) - ('', 55929)))), 6, ('mod2',)) \
    giving focus to <OverrideRedirectWindowModel object at 0x7fe604a64d20 (xpra+x11+gtk_x11+window+OverrideRedirectWindowModel at 0x1affa80)>
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/x11/gtk_x11/window.py", line 358, in do_xpra_property_notify_event
    if event.delivered_to is self.corral_window:
AttributeError: 'OverrideRedirectWindowModel' object has no attribute 'corral_window'
21:43,334 _focus(ServerSource(Protocol(SocketConnection(('', 1200) - ('', 55929)))), 0, ('mod2',)) \

It seems to be appearing whenever I scroll over and 'Like' posts. The observed behavior is as expected, but I assume the 'corral_window' is something that you use to handle drop down menus and it might be part of, or at least in the neighborhood of, the problem here.

Tue, 09 Jul 2013 22:24:14 GMT - alas:

Ok, just to make the oddness really extreme... even when there is a bar which will maintain focus holding the shift key down to type will only hold "cap focus" for two keystrokes, the third and all subsequent don't recognize the shift key being held (Caps Lock works as expected, though with Caps Lock engaged and the shift key pressed simultaneously, the "not-cap-focus" also holds for only two keystrokes, after which the shift key is ignored and the Caps Lock status re-asserts itself.)

Also, with a facebook comment box I can sometimes manage to hold focus in the box- until I do something to shift the focus... after which it can take dozens of frustrating tries to re-fix the focus. I haven't been able to reliably "fix" the focus, but using the arrow keys inside the comment box, or the address bar where the focus is jumping, seems to be a piece of the magic ritual. In case that's of any help. (Does the occasional working of it indicate some kind of race? between the focus and the override focus?)

Thu, 11 Jul 2013 13:11:04 GMT - Antoine Martin:

ValueError: unknown raw mode

Fixed in r3822

AttributeError: 'OverrideRedirectWindowModel' object has no attribute 'corral_window'

Fixed in r3821

Thu, 11 Jul 2013 16:24:59 GMT - Antoine Martin:

I've reverted most of r3713 in r3829 to stop the deluge of reports of focus issues.

The problem is not fixed however, even with just a simple xterm, it gets focus when first mapped about half the time, and simply moving the window is enough to make it gain or lose focus. Weird.

Fri, 12 Jul 2013 01:54:49 GMT - alas:

Agreed, the reversion solves the focus issues with the lazarus browser. There seems to be a lingering issue with the keyboard with osx client (not sure if it's a focus issue or some sort of thread lock issue).

Sat, 10 Aug 2013 05:19:32 GMT - Antoine Martin: status changed; resolution set

This particular bug is fixed by the revert, will follow up in #214 for 0.11.

Sat, 23 Jan 2021 04:52:55 GMT - migration script:

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