JDK-6404008 : REGRESSION: Mouse dragged events obey drag sensitivity
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-03-24
  • Updated: 2015-02-23
  • Resolved: 2006-05-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b85Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
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 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.
11-04-2006

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

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

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

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

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