A DESCRIPTION OF THE REGRESSION :
Mouse dragged events are not delivered when the sensitivity threshold is not reached. This poses a problem for my GUI builder as moving components does not work correctly anymore. The user can not any longer move a component by 1 pixel, they have to move a component about 15 pixels and then move the component 14 pixels back. On windows the threshold seems to be taken from the windows registry: HKEY_CURRENT_USER/Control Panel/Desktop/DragWith (DragHeight). When the threshold is set to 30, the mouse needs to be dragged about 15 pixels until I receive a mouseDragged event on the panel.
REPRODUCIBLE TESTCASE OR STEPS TO REPRODUCE:
public class MouseDragTest
public static void main(String args)
JFrame frame = new JFrame();
public void mousePressed(MouseEvent e)
System.out.println("pressed at (" + e.getX() + ", " + e.getY() + ")");
public void mouseDragged(MouseEvent e)
System.out.println("dragged at (" + e.getX() + ", " + e.getY() + ")");
public void mouseMoved(MouseEvent e)
frame.setBounds(100, 100, 200, 200);
Sample output while pressing & dragging the mouse on the frames contentPane (1.5.0_06):
pressed at (99, 58)
dragged at (99, 59)
dragged at (99, 60)
dragged at (99, 61)
dragged at (99, 62)
dragged at (99, 63)
dragged at (99, 64)
The mouseDragged handler is invoked for every pixel the mouose is dragged.
The same procedure tested on Java(TM) SE Runtime Environment (build 1.6.0-beta2-b76)
pressed at (84, 53)
dragged at (84, 69)
dragged at (84, 70)
dragged at (84, 71)
dragged at (84, 72)
dragged at (84, 73)
dragged at (84, 74)
the first dragged event is received after the mouse is moved 15 pixels from the starting point (threshold/2).
RELEASE LAST WORKED:
5.0 Update 6
RELEASE TEST FAILS:
EXPECTED VERSUS ACTUAL BEHAVIOR :
The mouse dragged listener should be notified for every mouse event and should not obey the drag sensitivity setting of the operating system.
Mouse dragged events are received after the drag sensitivity setting of the operating system is reached.
OBSERVED APPLICATION IMPACT:
Probably every java application using MouseMotionListeners will change the behaviour.
Posted Date : 2006-03-24 22:44:23.0
Mouse dragged events are not sent till the mouse passes the threshold.
AFAIK, this was an intentional change.
Posted Date : 2006-03-27 09:46:37.0
The effect you observing is the sequence of the bugfix #5039416 that has 13 votes, several duplicates and it also has a strong businesscase therefore it also fixed in JDK5.0 update release.
For the reasons stated above I'm closing this CR as not a defect.
Posted Date : 2006-03-27 10:13:26.0
Forgot to mention that this is an intentional change within 5039416.
Posted Date : 2006-03-30 10:37:51.0
With regard to a huge number of applications depending on that fix we should to re-fix 5039416 in other manner.
The idea of the fix is to restore JDK1.3 behavior that don't respect SM_CXDRAG/SM_CYDRAG properties. This means JDK will fire MouseDragged events in a SMUDGE area too.
Access to desktop properties would allow any java application to honor or not to honor this value and handle/initiate drag operations more flexible.
Posted Date : 2006-04-04 12:02:45.0
The fix shouldn't introduce any kind of inconsistency between platforms. Now that smudge area is 4x4 pixels wide by default and may not be replaced by the dekstop value(seem 6212197 integration will not affect this case and Java still not honor desktop drag threshold).
I verified XAWT binaries and they works fine with existing tests. Drag for event happens event on a small range there. And this is the same as on Windows. Inspecting the code shows that SMUDGE is only used in multiclick cases and shouldn't affect common drag sequence. So we shouldn't care about XAWT and Win32 inconsisyency.
Posted Date : 2006-04-11 13:42:44.0