This issue was filed on Debian:
I tried running firefox in xpra, and I could not click most UI elements.
Examining closely I found that the mouse pointer is way more to the right (like 50~100px) than what xpra thinks.
Minimizing the firefox window and restoring seems to fix the issue.
However, mouse is heavily used in X. Inability to rely on cursor position being what it appears to be makes the clients in xpra kind of hard to use.
Cannot reproduce.
I have never ever seen a problem like this one with the cursor. If it was ever seen, a bug like this one would be top priority.
Please provide full details:
etc..
FYI: I've just seen something similar for the first time ever, and this had nothing to do with xpra (it was not even running or installed in that VM), it was something to do with VirtualBox
... Are you sure you gave us all the details?
It happens to me with VirtualBox
quite often, and this is unrelated to Xpra. It can also happen when the server and client resolution in Xpra don't match.
I think I've just had it without VirtualBox
, with Firefox
- there was this error on stdout when it happened, which may well be relevant:
/usr/lib64/python2.7/site-packages/xpra/client_window.py:259: \ GtkWarning: IA__gtk_window_set_type_hint: assertion `!gtk_widget_get_mapped (GTK_WIDGET (window))' failed self.set_type_hint(hint)
The warning above is fixed by r1269 - not sure it was relevant now.
Cannot reproduce - closing.
I suspect that this has something to do with the client's window manager re-positioning the window when we map it: we send the configure event before/after this, causing the mismatch. If this is the case, simply moving the window should fix it.
This is exactly what's happening with Firefox a.k.a. Iceweasel -- when browser starts it restores its profile and window size/position so mouse cursor misses until window moved or Xpra client re-attached.
Can you provide a log sample taken with "xpra -d all ...
" of when the window appears?
There should be events telling us where it is (that we forward to the server).
Here it is, last click before client disconnect misses its target.
That file is huge! Is this really just when the window appears on screen? (that's what I need)
Sorry, it's clean start of Iceweasel, first it show its "choose profile dialog" then after I click for the first time it displays its main window. After some time when it's loaded I click again (that's the one that misses) and immediately disconnect. I wasn't sure if I keep exactly what you're looking for if I trim the log...
I cannot reproduce here (although I think I might have seen this a long time ago - maybe using a different DE), I suspect this is related to client-side DE positioning. Which DE do you use?
Can you try with the attached patch? You should get log output looking like this:
Got configure event: <gtk.gdk.Event at 0x2b08670: GDK_CONFIGURE x=4, y=46, width=499, height=316>, geometry=(4, 46, 499, 316) Got configure event: <gtk.gdk.Event at 0x2b08788: GDK_CONFIGURE x=6, y=69, width=499, height=316>, geometry=(6, 69, 499, 316) Got configure event: <gtk.gdk.Event at 0x2b08788: GDK_CONFIGURE x=6, y=69, width=499, height=316>, geometry=(6, 69, 499, 316) Got map event: <gtk.gdk.Event at 0x2b08788: GDK_MAP>, geometry=(6, 69, 499, 316) Got configure event: <gtk.gdk.Event at 0x2b088a0: GDK_CONFIGURE x=45, y=24, width=1277, height=1312>, geometry=(45, 24, 1277, 1312) Got configure event: <gtk.gdk.Event at 0x2b088a0: GDK_CONFIGURE x=47, y=47, width=1277, height=1312>, geometry=(47, 47, 1277, 1312) Got configure event: <gtk.gdk.Event at 0x2b088a0: GDK_CONFIGURE x=47, y=47, width=1277, height=1312>, geometry=(47, 47, 1277, 1312) Got map event: <gtk.gdk.Event at 0x2b088a0: GDK_MAP>, geometry=(47, 47, 1277, 1312) Got configure event: <gtk.gdk.Event at 0x2b08788: GDK_CONFIGURE x=169, y=178, width=1277, height=1312>, geometry=(169, 178, 1277, 1312)
This should help us spot any discrepancies. Maybe we need to send the window location on the map event rather than on "configure". I am only interested in events showing the problem, so please discard log data for windows that did *not* have position issues. (but don't trim too much either!)
Also, are there any other applications that show this problem? Firefox generates tons of traffic and it is generally one of the worst applications you can run in xpra.
will print out debug information about window position map and configure events
With debug-window-position.patch client printed the following as soon as iceweasel shown its window:
2012-10-08 22:16:40,896 Got map event: <gtk.gdk.Event at 0x17c71c0: GDK_MAP>, geometry=(35, 23, 1228, 801) 2012-10-08 22:16:40,911 Got configure event: <gtk.gdk.Event at 0x17c71c0: GDK_CONFIGURE x=35, y=23, width=1228, height=801>, geometry=(35, 23, 1228, 801)
Corresponding log taken with "-d all" is attached.
Thanks.
Was the problem happening when this log was taken? Both events agree on the location of the window.. How much was it off by?
Also, I can't explain why it would be off horizontally and not vertically..
debugging patch for the server side of the window positionnng code
r2114 adds a test case for this, it is the application that is moving its own window and we fail to handle that.. fix should not take too long now that I can reproduce and know where to look (WindowModel.composite_configure_event
only handles changes in dimensions at present)
fixed in r2116 by resetting the client window location to where we want it to be - we should try to honour the moves, see #212
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/158