xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 3 years ago

Last modified 4 months ago

#1941 assigned defect

Java Mouse Location Incorrect when moving a window — at Version 3

Reported by: Mark Harkin Owned by: Antoine Martin
Priority: critical Milestone: 4.2
Component: server Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

I have an undecorated window that I want to move by dragging the panel inside. However under the scenario WindowDragNoDelay the window jumps erratically with the mouse position read incorrectly in Java (also printed to stdout).

Through debugging I've 2 scenarios (WindowDragWithDelay,WindowDragNoMove) that can return the mouse location correctly and 1 (WindowDragNoDelay) that doesn't.

As a control (CentOS without Xpra) WindowDragNoDelay will return the correct mouse location.

Reproduce by installing java and running the windowdrag.jar in attached zip file:

java -cp windowdrag.jar WindowDragNoDelay
java -cp windowdrag.jar WindowDragWithDelay
java -cp windowdrag.jar WindowDragNoMove

Can attach logs if you provide the log categories you want.

Python Client on Windows 10 (also can reproduce with HTML5 client)
Server on CentOS 7.
Client and server both on revision r20214

Change History (5)

Changed 3 years ago by Mark Harkin

Attachment: WinDrag.zip added

Sample jar and source

comment:1 Changed 3 years ago by Mark Harkin

Component: javaserver

comment:2 Changed 3 years ago by Antoine Martin

Description: modified (diff)
Priority: majorcritical
Status: newassigned

Changed 3 years ago by Antoine Martin

disable pointer adjustments

comment:3 Changed 3 years ago by Antoine Martin

Description: modified (diff)

The patch above "fixes" the issue, but we can't apply it.

The problem comes from the fact that since the xpra server and client(s) can be detached and re-attached, each one has its own window model and each model can be different. For example, windows may not be shown on screen exactly where the server thinks they are. That's especially the case when you enable session sharing and connect with multiple clients.

So we keep track of where the clients map each window, and when we process pointer events from a client we adjust the position of the event so that it lands in exactly the same place on the server side window.
When running your example code, we create a race condition: the server moves the window and sends a message to the client to do likewise but before the client has a chance to do so it has sent a pointer motion event which then gets adjusted for the new window position the client knew nothing about at that point.. So we shouldn't adjust it, and that's why the patch "works".

Note: See TracTickets for help on using tickets.