[GTK] Reports wrong mouse coordinates when starting a drag

[tmssngr]

Describe the bug
A drag is detected after moving the mouse a few pixels. But SWT reports the drag with the coordinates after the drag was detected, not the coordinates where the left mouse button was pressed. This causes wrong elements to be dragged in our application.

To Reproduce

import org.eclipse.swt.*;
import org.eclipse.swt.dnd.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;

public class DragDropPositions {

	public static void main(String[] args) {
		final Display display = new Display();

		final Shell shell = new Shell(display);

		final Listener listener = event -> {
			switch (event.type) {
			case SWT.MouseMove -> System.out.println("move: " + new Point(event.x, event.y));
			case SWT.MouseDown -> System.out.println("down: " + new Point(event.x, event.y));
			case SWT.KeyDown -> System.out.println("key " + shell.toControl(display.getCursorLocation()));
			}
		};
		shell.addListener(SWT.MouseMove, listener);
		shell.addListener(SWT.MouseDown,listener);
		shell.addListener(SWT.KeyDown,listener);

		final DragSource dragSource = new DragSource(shell, DND.DROP_MOVE);
		dragSource.setTransfer(TextTransfer.getInstance());
		dragSource.addDragListener(new DragSourceAdapter() {
			@Override
			public void dragStart(DragSourceEvent event) {
				System.out.println("drag start " + shell.toControl(event.x, event.y));
			}

			@Override
			public void dragSetData(DragSourceEvent event) {
				event.data = new String[] {""};
			}
		});
		final DropTarget target = new DropTarget(shell, DND.DROP_MOVE);
		target.setTransfer(TextTransfer.getInstance());
		target.addDropListener(new DropTargetAdapter() {
			@Override
			public void dragEnter(DropTargetEvent event) {
				System.out.println("drop enter " + shell.toControl(event.x, event.y));
				event.detail = DND.DROP_NONE;
			}

			@Override
			public void drop(DropTargetEvent event) {
				event.detail = DND.DROP_NONE;
			}
		});

		shell.setSize(400, 300);
		shell.open();

		while (!shell.isDisposed()) {
			if (!display.readAndDispatch()) {
				display.sleep();
			}
		}

		display.dispose();
	}
}

• start this snippet
• mouse the cursor over the shell -> a lot of move-events are logged
• press a key (just to mark the line in the logged output)
• without moving the mouse, press and hold the left mouse button -> nothing is logged
• move the mouse a couple of pixels down until logging occurs
• release the mouse button

My logging looks like this:

...
move: Point {251, 76}
key Point {251, 76}
move: Point {251, 77}
move: Point {251, 78}
move: Point {252, 78}
move: Point {252, 79}
move: Point {253, 80}
move: Point {253, 82}
move: Point {253, 83}
move: Point {253, 85}
down: Point {251, 75}
drag start Point {254, 84}
move: Point {255, 87}
drop enter Point {254, 86}
move: Point {262, 110}
...

• notice:
  • although the left mouse button has pressed before moving the mouse, the move-events occur before the down-event
  • the coordinates of the drag start event differ from the down-event (hence you can't use it to determine the dragged element!)

Expected behavior

• the mouse-down event must occur before the mouse-move events
• the drag-start event must contain the coordinates of the mouse-down position

Environment:

1. Select the platform(s) on which the behavior is seen:

• • All OS
• • Windows
• • Linux
• • macOS

2. Additional OS info (e.g. OS version, Linux Desktop, etc)
   Fedora 42 KDE

[tmssngr]

The bug is better noticable when logging the event.stateMask, too:

			case SWT.MouseMove -> System.out.println("move: " + new Point(event.x, event.y) + " " + Integer.toHexString(event.stateMask));

Then the output looks like this:

move: Point {160, 67} 0
move: Point {161, 68} 80000
move: Point {161, 69} 80000
move: Point {161, 69} 80000
move: Point {161, 70} 80000
move: Point {162, 71} 80000
move: Point {162, 71} 80000
move: Point {162, 72} 80000
move: Point {163, 72} 80000
move: Point {163, 73} 80000
move: Point {163, 73} 80000
move: Point {163, 74} 80000
move: Point {164, 75} 80000
move: Point {164, 74} 80000
move: Point {164, 75} 80000
move: Point {164, 76} 80000
down : Point {159, 67}
drag start Point {164, 76}
move: Point {165, 78} 80000
move: Point {165, 78} 80000
move: Point {165, 80} 80000

In other words, the MouseMove-event already is sent with the first-button's bit set before even having sent the MouseDown event.
I recommend to ignore all the MouseMove events with the first-button's bit set before sending the MouseDown event. They only confuse application code.

[tmssngr]

The PR #2574 fixes one part of this bug (the MouseMove events with BUTTON1 bit set).