United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6404008 REGRESSION: Mouse dragged events obey drag sensitivity
JDK-6404008 : REGRESSION: Mouse dragged events obey drag sensitivity

Details
Type:
Bug
Submit Date:
2006-03-24
Status:
Resolved
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2006-05-12
Component:
client-libs
OS:
windows_xp
Sub-Component:
java.awt
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
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();

        frame.getContentPane().addMouseListener(new MouseAdapter()
        {
            public void mousePressed(MouseEvent e)
            {
                System.out.println("pressed at (" + e.getX() + ", " + e.getY() + ")");
            }
        });

        frame.getContentPane().addMouseMotionListener(new MouseMotionListener()
        {
            public void mouseDragged(MouseEvent e)
            {
                System.out.println("dragged at (" + e.getX() + ", " + e.getY() + ")");
            }


            public void mouseMoved(MouseEvent e)
            {
            }
        });

        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setBounds(100, 100, 200, 200);
        frame.setVisible(true);
    }
}

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:
mustang-beta

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The mouse dragged listener should be notified for every mouse event and should not obey the drag sensitivity setting of the operating system.
ACTUAL -
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.

                                    

Comments
EVALUATION

Mouse dragged events are not sent till the mouse passes the threshold.
AFAIK, this was an intentional change.
                                     
2006-03-27
EVALUATION

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.
                                     
2006-03-27
EVALUATION

Forgot to mention that this is an intentional change within 5039416.
                                     
2006-03-30
EVALUATION

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.
                                     
2006-04-04
EVALUATION

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.
                                     
2006-04-11
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/awt_data/mustang/6404008.1/
                                     
2006-04-11



Hardware and Software, Engineered to Work Together