JDK-8164454 : setLocationRelativeTo() puts Window on the 1-st (default) screen of two.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • Submitted: 2016-08-19
  • Updated: 2017-10-16
  • Resolved: 2017-10-16
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 10
10Resolved
Related Reports
Relates :  
JDK-8160270 - dual-screen issue with java.awt.Choice
Description
Run the attached test with jdk9 on a dual-screen Linux system with Xinerama. I have two Ubuntu 16.04 systems. It will create a Frame using the simplest constructor presuming default graphics configuration but puts it anywhere on the second screen, which is extension of the first one.
A Window with that Frame as a parent is setLocationRelativeTo(parent).  Now, this Window appears on the first screen.
Perhaps it is the same issue as JDK-8160270 but more general, so this bug should not be closed as a duplicate of that P4.

There used to be several issues re: relative location. Using different builds of JDK9 and putting the parent Frame in different locations across the virtual screen, one could see a lot of strange things -- but now most of them are fixed. This issue, however, is reproducible consistently starting from b112 at least.
Comments
No, it is a separate test which is not included in JDK tests.
16-10-2017
is it a test issue to keep open as a test bug?
16-10-2017
Actually, this is not a bug. When another screen coordinates are assigned to a frame its graphics configuration will be correspondingly updated only after the native platform finishes to move the window, so the relative position captured by the Component::setLocationReletiveTo(frame) may be wrong if the frame transition is not finished yet. The bug scenario can be fixed by inserting a small delay between f.setVisible(true) and rw.setLocationRelativeTo(f).
16-10-2017
Targeted to 10 as an issue introduced in 8u or 9
17-02-2017
RULE "closed/java/awt/Choice/ChoiceHandleMouseEvent_2/ChoiceHandleMouseEvent_2" Exception java.lang.RuntimeException: Test failed. Exception thrown: java.lang.RuntimeException: Stage ...
16-02-2017
most likely a duplicate of JDK-8163101
21-10-2016
Approved by component triage team to defer
13-09-2016
Indeed. Bizarre! Thank you, Ajit. SQE: JDK 9: OK to defer.
13-09-2016
This looks like a timing issue. On Unity, window appearance animation takes some time (this is what I could see visually) Workaround : if we wait for the parent frame to be completely visible (f.setVisible does not make it visible immediately) I tried introducing a sleep of 1sec or 2sec after f.setVisible(true) call. With this change, the red colored window appears at correct location. Requesting this to be deferred for 9.
13-09-2016
Tested with - Ubuntu 16.04 - Unity - Dual screen setup - 9b132. Issue is reproducible - red window is always put on screen-1 of the dual screen system.
22-08-2016