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.
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.
Please post focus debug messages using the patch from #214
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.
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:
xpra info with mouse hovering over youtube searchbar
xpra info with mouse not hovering over youtube searchbar (over address bar)
xpra info with mouse over xterm showing as GIANT cursor
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.
copied output from server with focus debug patch
Another xpra info with youtube search bar in focus (using alt-tab to get to window to run xpra info)
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).
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
Trimming the logs for things of interest:
window.has-alpha=True window.override-redirect=True window.window-type=('TOOLTIP',)
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".
xpra info with focus in search bar (captured from different machine)
xpra info with focus in address bar (not search bar, captured with different machine)
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.
server debug and error logs from clicking into youtube search bar
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.
Logs showing tracebacks with drop menus similar to those from focus issues
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.
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(('10.0.32.196', 1200) - ('10.0.11.67', 55929)))), 6, ('mod2',)) \ has_focus=0 21:39,644 focus(ServerSource(Protocol(SocketConnection(('10.0.32.196', 1200) - ('10.0.11.67', 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(('10.0.32.196', 1200) - ('10.0.11.67', 55929)))), 0, ('mod2',)) \ has_focus=6
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.
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?)
ValueError: unknown raw mode
Fixed in r3822
AttributeError: 'OverrideRedirectWindowModel' object has no attribute 'corral_window'
Fixed in r3821
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.
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).
This particular bug is fixed by the revert, will follow up in #214 for 0.11.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/366