xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 6 years ago

#366 closed defect (fixed)

cursor focus error created somewhere between r3680 and 3725 server revisions

Reported by: alas Owned by: alas
Priority: major Milestone:
Component: client Version:
Keywords: Cc:

Description

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.

Attachments (9)

tubesearchbar.txt (30.3 KB) - added by alas 6 years ago.
xpra info with mouse hovering over youtube searchbar
tubenotsearchbar.txt (24.1 KB) - added by alas 6 years ago.
xpra info with mouse not hovering over youtube searchbar (over address bar)
bigcursorinfo.txt (16.2 KB) - added by alas 6 years ago.
xpra info with mouse over xterm showing as GIANT cursor
focusDebugPatchOutput (8.0 KB) - added by alas 6 years ago.
copied output from server with focus debug patch
tubefocustest.txt (51.8 KB) - added by alas 6 years ago.
Another xpra info with youtube search bar in focus (using alt-tab to get to window to run xpra info)
bettertubesearchinfo.txt (57.9 KB) - added by alas 6 years ago.
xpra info with focus in search bar (captured from different machine)
bettertubenotsearchinfo.txt (51.8 KB) - added by alas 6 years ago.
xpra info with focus in address bar (not search bar, captured with different machine)
r3778-server-log-youtube (4.0 KB) - added by alas 6 years ago.
server debug and error logs from clicking into youtube search bar
r3778-server-log-dropmenu-tracebacks (8.1 KB) - added by alas 6 years ago.
Logs showing tracebacks with drop menus similar to those from focus issues

Download all attachments as: .zip

Change History (25)

comment:1 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

Please post focus debug messages using the patch from #214

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

  • not display the error on win32, we just have to live with it
  • not bother sending the transparency channel to clients that cannot handle transparency (waste if bandwidth)

Changed 6 years ago by alas

Attachment: tubesearchbar.txt added

xpra info with mouse hovering over youtube searchbar

Changed 6 years ago by alas

Attachment: tubenotsearchbar.txt added

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

Changed 6 years ago by alas

Attachment: bigcursorinfo.txt added

xpra info with mouse over xterm showing as GIANT cursor

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

Changed 6 years ago by alas

Attachment: focusDebugPatchOutput added

copied output from server with focus debug patch

Changed 6 years ago by alas

Attachment: tubefocustest.txt added

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

comment:4 Changed 6 years ago by alas

Status: newassigned

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

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

comment:6 Changed 6 years ago by Antoine Martin

Trimming the logs for things of interest:

window[10].has-alpha=True
window[10].override-redirect=True
window[10].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".

Last edited 6 years ago by Antoine Martin (previous) (diff)

Changed 6 years ago by alas

Attachment: bettertubesearchinfo.txt added

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

Changed 6 years ago by alas

Attachment: bettertubenotsearchinfo.txt added

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

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

comment:8 Changed 6 years ago by Antoine Martin

  • r3771 avoids printing the warning on win32
  • r3772 avoids sending transparency data to clients that do not support it (only for png encoding for now)

Changed 6 years ago by alas

Attachment: r3778-server-log-youtube added

server debug and error logs from clicking into youtube search bar

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

Changed 6 years ago by alas

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

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

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

Last edited 6 years ago by Antoine Martin (previous) (diff)

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

comment:13 Changed 6 years ago by Antoine Martin

ValueError: unknown raw mode

Fixed in r3822


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

Fixed in r3821

Last edited 6 years ago by Antoine Martin (previous) (diff)

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

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

comment:16 Changed 6 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.