Xpra: Ticket #158: xpra: mouse position out of sync

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.

Fri, 06 Jul 2012 19:01:55 GMT - daemonpnz: cc set

Fri, 20 Jul 2012 05:13:56 GMT - Antoine Martin:

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:


Sat, 21 Jul 2012 08:37:06 GMT - Antoine Martin:

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?

Sat, 21 Jul 2012 08:48:04 GMT - ahuillet:

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.

Sat, 04 Aug 2012 04:22:21 GMT - Antoine Martin: status changed

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

Sat, 04 Aug 2012 13:32:39 GMT - Antoine Martin:

The warning above is fixed by r1269 - not sure it was relevant now.

Mon, 20 Aug 2012 13:18:46 GMT - Antoine Martin: status changed; resolution set

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.

Thu, 04 Oct 2012 15:33:17 GMT - onlyjob:

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.

Thu, 04 Oct 2012 15:33:24 GMT - onlyjob: cc changed

Thu, 04 Oct 2012 15:35:11 GMT - Antoine Martin: status changed; resolution deleted

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

Thu, 04 Oct 2012 16:03:53 GMT - onlyjob: attachment set

Thu, 04 Oct 2012 16:05:16 GMT - onlyjob: version changed

Here it is, last click before client disconnect misses its target.

Thu, 04 Oct 2012 16:07:18 GMT - Antoine Martin: milestone changed

That file is huge! Is this really just when the window appears on screen? (that's what I need)

Thu, 04 Oct 2012 16:14:17 GMT - onlyjob:

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

Mon, 08 Oct 2012 10:28:35 GMT - Antoine Martin: description changed

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.

Mon, 08 Oct 2012 10:29:08 GMT - Antoine Martin: attachment set

will print out debug information about window position map and configure events

Mon, 08 Oct 2012 11:19:11 GMT - onlyjob: attachment set

Mon, 08 Oct 2012 11:21:07 GMT - onlyjob:

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.


Mon, 08 Oct 2012 11:22:44 GMT - Antoine Martin:

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

Tue, 13 Nov 2012 07:22:19 GMT - Antoine Martin: attachment set

debugging patch for the server side of the window positionnng code

Tue, 13 Nov 2012 07:32:25 GMT - Antoine Martin:

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)

Tue, 13 Nov 2012 09:20:20 GMT - Antoine Martin: status changed; resolution set

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

Sat, 23 Jan 2021 04:47:07 GMT - migration script:

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