Bug ID: JDK-8324666 JFXPanel: Japanese IME window initially shown in the corner (Windows)

Versions (Unresolved/Resolved/Fixed)

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
tbdUnresolved

To reproduce:
- run the attached application on Windows 11
- change the input language to Japanese/Hiragana (あ shows up in addition to JP in the windows toolbar)
- type in 'a'

Upon first launch , the IME window appears in the bottom right corner instead of near the text field. Dismiss, type - the windows appears where it's supposed to be.

See also
https://github.com/openjdk/jfx/pull/1337#issuecomment-1901265779

Contrary to this comment 
https://github.com/openjdk/jfx/pull/1337#issuecomment-1901527510
the issue cannot be reproduce with JTextField in a regular JFrame, so it must be related to JFXPanel.

[~angorya] Probably a timing issue; there's some thread-hopping and posted events involved. In any case I'm not a good candidate to investigate this bug. I think the next step is to crack open the openCandidateWindow code in AWT but it's native and I have no experience with the AWT native code or the Windows API calls that manipulate the IME.
25-01-2024
[~mfox] Do you think it's another concurrency issue or just some poor design? Would you like to take on this bug?
25-01-2024
I was able to reproduce with a pure Swing app but it is rare. I always ensure the Japanese IME is active before launching the test. After launching I check to see if the IME is in alphanumeric mode (there's an "A" in the taskbar"). If it is I click once on the "A" to switch to Hiragana and then start typing. This always reproduces the problem in a JFXPanel and sometimes does so in a pure Swing app. If I set a breakpoint on the call to openCandidateWindow in WInputMethod.java it's clear that the IME window is being positioned and shown before AWT is asking where it should go. Then multiple calls are being made to inquireCandidatePosition each one leading to a call to openCandidateWindow. For Swing this usually gets the IME window correctly placed, for JavaFX it rarely does. In both cases it looks like correct coordinates are being passed in.
25-01-2024
[~mfox] I could not reproduce this issue in pure swing, so it must be related to JFXPanel...
24-01-2024

Relates :	JDK-8088485 - Windows 8, Chinese input method candidate window is always placed at the bottom of the screen.
Relates :	JDK-8322784 - JFXPanel calls InputMethodRequests on wrong thread