JDK-8019364 : [macosx] MouseEvent has wrong coordinates when using multiple monitors
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u6,8
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • Submitted: 2013-06-28
  • Updated: 2013-08-14
  • Resolved: 2013-08-14
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 8
8Resolved
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
Happens with both:
java version  " 1.7.0_25 " 
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

java version  " 1.7.0_40-ea " 
Java(TM) SE Runtime Environment (build 1.7.0_40-ea-b29)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b48, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Mac OS X 10.8.4

Darwin Geoffs-MacBook-Pro.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May  1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64

EXTRA RELEVANT SYSTEM CONFIGURATION :
Using an external monitor (connected with a DisplayLink USB-to-DVI adapter)

A DESCRIPTION OF THE PROBLEM :
I have a laptop with an external monitor connected. When I open a Java window running my application and drag it to the external monitor, mouse events are received in the application with completely bogus Y screen coordinates. That is, MouseEvent.getYOnScreen() returns a number that's a few hundred pixels away from the real location.

REGRESSION.  Last worked in version 6u45

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached test program, drag it onto your second monitor, and wave your mouse over the frame.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No console output.
ACTUAL -
mismatch (1725,-341) != (1725,-161)
mismatch (1710,-334) != (1710,-154)
mismatch (1697,-325) != (1697,-145)
mismatch (1691,-320) != (1691,-140)
mismatch (1678,-310) != (1678,-130)
mismatch (1662,-298) != (1662,-118)

etc...

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;

public class Test extends MouseAdapter implements Runnable {
  public void mouseMoved(MouseEvent e) {
    Point p = e.getPoint();
    SwingUtilities.convertPointToScreen(p, e.getComponent());
    if (p.x != e.getXOnScreen() || p.y != e.getYOnScreen()) {
      System.out.println( " mismatch ( "  + p.x +  " , "  + p.y +  " ) != ( "  + e.getXOnScreen() +  " , "  + e.getYOnScreen() +  " ) " );
    }
  }

  public void run() {
    JPanel panel = new JPanel();
    panel.setPreferredSize(new Dimension(300, 300));
    panel.addMouseMotionListener(this);

    JFrame frame = new JFrame();
    frame.add(panel);
    frame.pack();
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setVisible(true);
  }

  public static void main(String[] args) {
    SwingUtilities.invokeLater(new Test());
  }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The relative coordinates seem to be correct. My workaround is to use reflection to overwrite MouseEvent.xAbs and MouseEvent.yAbs with values obtained from SwingUtilities.convertPointToScreen.
Comments
It's quite ordinary situation for modern Mac development, to use 2 screens. We may not have escalations but developers will not agree to defer
13-08-2013

This issue occurs due to wrong absY was calculated relative to screen containing window, not to primary screen. According to documentation primary screen can be obtained via [[NSScreen screens] objectAtIndex:0]: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSScreen_Class/Reference/Reference.html#//apple_ref/occ/clm/NSScreen/screens The screen at index 0 in the returned array corresponds to the primary screen of the user���s system. Possible fix: --- a/src/macosx/native/sun/awt/AWTView.m Fri Jun 21 21:30:12 2013 +0400 +++ b/src/macosx/native/sun/awt/AWTView.m Thu Jul 18 15:13:39 2013 +0400 @@ -347,7 +347,7 @@ // TODO: need consitent way for doing that both with global as well as with local coordinates. // The reason to do it here is one more native method for getting screen dimension otherwise. - NSRect screenRect = [[NSScreen mainScreen] frame]; + NSRect screenRect = [[[NSScreen screens] objectAtIndex:0] frame]; absP.y = screenRect.size.height - absP.y; jint clickCount;
18-07-2013

8-defer-request: the issue from 7 GA (7u6 on Mac OS X), isn't escalated by customers
03-07-2013

Not a regression. Reproducible with 7u6, 7u40 and 8
03-07-2013