Bug ID: JDK-8174688 JavaFX Applet popup windows are in the wrong location on Mac

Type: Bug
Component: javafx
Sub-Component: graphics
Affected Version: 8u121,9

Priority: P3
Status: Resolved
Resolution: Fixed
OS: os_x

Submitted: 2017-02-09
Updated: 2020-01-31
Resolved: 2017-02-14

JDK 8	JDK 9
8u152Fixed	9Fixed

Now that JDK-8173154 is fixed we can see that JavaFX popup windows (for example the dropdowns of comboboxes) appear in the wrong location on the screen.  If you move the window then they will appear correctly just under their associated control.

Approved to backport to 8u-dev for 8u152. +1
17-02-2017
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/165c760d73c8
14-02-2017
The fix looks fine to me, including the additional lines of change which only touch comments and on debug LOG message. I tested it on 10.9.5 and the problem is fixed. +1 to push to 9-dev
13-02-2017
2/13/2017: On review: webrev: http://cr.openjdk.java.net/~flar/JDK-8174688/webrev.00/
13-02-2017
The same problem happens on jdk8b121. The same patch applies to the 8u-dev repo (with source filenames updated) and appears to fix the bug there as well.
13-02-2017
This same code appears in the 8u-dev sources, but I haven't tried reproducing it there yet.
12-02-2017
There were a lot of really confusing symptoms here and it was hard to figure out how they all could have boiled down to one failure to invert the Y coordinate system, but fixing this one piece of code fixed all of the popups: http://cr.openjdk.java.net/~flar/JDK-8174688/webrev.00/ Note that I left a couple of other fixes in the webrev, but they can be deleted to reduce the scope if needed. In particular: - fixed some typos in the _getEmbeddedY() native method that I saw as I was adding debug print statements to it - wrote some code to be able to inject debugging output into the System.out stream so that it could be seen in context in the Java plugin logs. It isn't used now that I'm done debugging, but I thought I might leave it in there, commented out, in case we need to debug more stuff in the future...? An oddity about the code used in the fix is that there are a few places in the code that do this inversion and: - We should probably look to centralize this somewhere for one thing (there is an existing flipFrame method in one of the files, but it isn't clear if it can be used in these cases). - All of them seem to invert based on Screen index 0, which makes it sound as if it will fail on a dual monitor system, but it worked fine on my dual monitor system. I think the only issue is that the FX code may see bad numbers for where these embedded windows live on the secondary screens, but as long as the translation between the Java coordinate system and the Mac screen coordinate systems are consistent, no actual bugs happen in practice. It may also be a problem if an applet or embedded app decides to open a window at an absolute coordinate based on the Screen objects - those objects may appear in the wrong location, but for code that tries to position a sub-window below another widget measured against coordinates that went through a similar "screen 0 inversion", the relative locations should work fine for now. It's hard to tell without writing more test cases, but if a further fix is needed for this issue then it will be much more systemic than making this one call site consistent with the others to fix this current bug... I'll file a couple of low priority follow-on bugs to investigate those 2 issues, but for now the popups are appearing properly with this fix (that copies the paradigm from other related code).
12-02-2017
I'm on 10.11.6 for reference...
09-02-2017
I noticed the same behavior (Mac OS X 10.9.5) when I was testing the fix for JDK-8173154
09-02-2017