xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 6 years ago

#158 closed defect (fixed)

xpra: mouse position out of sync

Reported by: أحمد المحمودي Owned by: Antoine Martin
Priority: major Milestone: 0.7
Component: core Version: trunk
Keywords: Cc: daemon-pnz@…, onlyjob@…

Description (last modified by Antoine Martin)


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.

Attachments (4)

xpra_trunk_t158_a.log.xz (92.9 KB) - added by onlyjob 6 years ago.
debug-window-position.patch (1.6 KB) - added by Antoine Martin 6 years ago.
will print out debug information about window position map and configure events
158_debug-window-position.log.xz (46.0 KB) - added by onlyjob 6 years ago.
debug-window-position-changes.patch (895 bytes) - added by Antoine Martin 6 years ago.
debugging patch for the server side of the window positionnng code

Download all attachments as: .zip

Change History (22)

comment:1 Changed 6 years ago by daemonpnz

Cc: daemon-pnz@… added

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

  • distro version, both client and server
  • xpra full version info (identical on client and server?)
  • full command lines used - without omitting anything, however trivial
  • Xorg full version info
  • Firefox full version info
  • have you tried with Xdummy?
  • do any other apps show this odd behaviour?

etc..

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

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

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

comment:5 Changed 6 years ago by Antoine Martin

Status: newaccepted

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)

comment:6 Changed 6 years ago by Antoine Martin

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

comment:7 Changed 6 years ago by Antoine Martin

Resolution: needinfo
Status: acceptedclosed

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.

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

comment:9 Changed 6 years ago by onlyjob

Cc: onlyjob@… added

comment:10 Changed 6 years ago by Antoine Martin

Resolution: needinfo
Status: closedreopened

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

Changed 6 years ago by onlyjob

Attachment: xpra_trunk_t158_a.log.xz added

comment:11 Changed 6 years ago by onlyjob

Version: 0.3.2trunk

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

comment:12 Changed 6 years ago by Antoine Martin

Milestone: 0.40.7

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

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

comment:14 Changed 6 years ago by Antoine Martin

Description: modified (diff)

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.

Changed 6 years ago by Antoine Martin

Attachment: debug-window-position.patch added

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

Changed 6 years ago by onlyjob

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

Thanks.

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

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

Changed 6 years ago by Antoine Martin

debugging patch for the server side of the window positionnng code

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

comment:18 Changed 6 years ago by Antoine Martin

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.