JDK-8186063 : Robot.mouseMove doesn't work first try on scaled 175% 4K screen
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8u144
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_10
  • CPU: x86
  • Submitted: 2017-08-03
  • Updated: 2018-06-10
  • Resolved: 2018-06-10
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.
Other
tbd_majorResolved
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) Client VM (build 25.144-b01, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.15063]

EXTRA RELEVANT SYSTEM CONFIGURATION :
My laptop has 3840x2160 pixel and in the Display control panel I have it scaled to 175%.  I also have the display extended to a second screen to the right, aligned at the top, with 1920x1080 resolution.  I don't believe the second screen is relevant to the problem.

A DESCRIPTION OF THE PROBLEM :
I had noticed that my code was not positioning the mouse correctly during automated test steps.  My code does automated testing.  So I stopped in the IntelliJ IDEA debugger after the code had created a java.awt.Robot instance called gort.

In the expression evaluator in IDEA I typed in gort.mouseMove(860, 930) and the mouse moved to  (493, 532), as I determined by evaluating MouseInfo.getPointerInfo().getLocation().  Note that 493 = 860/1.75 and 532 = 930/1.75 if you round up.  Note that 1.75 is the Windows Display scale factor on that laptop screen.

Subsequent calls to moved the mouse to (860, 930).  If I assigned gort a new Robot the call would go back to (493, 532) on the first call and then (860, 930) on sebsequent calls almost every time.  Sometimes the correct result was obtained with 1 call and sometimes it took 3 but such cases were very rare.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Get a hi-res monitor such as I have (Dell Precision 7510).
If you run the code
(new Robot).mouseMove(860, 930)
it will fail almost always placing the mouse at (493, 532).  The easiest way is to use a debugger's expression evaluator for that.  

If instead you stop a debugger at a line of code where there is a local instance of java.awt.Robot you can do as I have:
gort = new Robot()
gort..mouseMove(860, 930)
gort..mouseMove(860, 930)
gort..mouseMove(860, 930)

You will typically observe the mouse move to the wrong coordinates as described above on the first call to mouseMove.  It seems that there is a very high likelihood that subsequent calls to the same Robot instance put the mouse in the correct position, though not a 100% likelihood.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The first call to Robot.mouseMove(860, 930) should put the mouse at those coordinates.
ACTUAL -
The first call to Robot.mouseMove with args (860, 930) puts the mouse at (493, 532) typically.  Also typically, a second such call using the same Robot will move the mouse to (860, 930).  With a new Robot instance the mistake recurs.  It makes no difference which constructor is used for the Robot that I was able to observe.

REPRODUCIBILITY :
This bug can be reproduced often.

---------- BEGIN SOURCE ----------

Any source code that pops up a window will do.  I've been using SwingSet2 for the window and stopping at a breakpoint in the extension that I use for automated testing.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Call Robot.mouseMove in a loop that exits when the mouse is at the desired location, for instance comparing with results from MouseInfo class.  A timeout on the loop isn't a bad idea either.


Comments
Does it affect 9?
10-08-2017

The issue is reported reproducible with high resolution system (3840x2160). To verify run the attached test case.
10-08-2017