JDK-8322784 : JFXPanel calls InputMethodRequests on wrong thread
  • Type: Bug
  • Component: javafx
  • Sub-Component: swing
  • Affected Version: jfx21,jfx22
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-12-29
  • Updated: 2024-07-23
  • Resolved: 2024-01-23
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
jfx23 b02Fixed
Related Reports
Blocks :  
JDK-8221261 - Deadlock on macOS in JFXPanel app when handling IME calls
Blocks :  
JDK-8090267 - JFXPanel Input Problem
Relates :  
JDK-8322703 - Intermittent crash in WebView in a JFXPanel from IME calls on macOS
Relates :  
JDK-8221261 - Deadlock on macOS in JFXPanel app when handling IME calls
Relates :  
JDK-8324666 - JFXPanel: Japanese IME window initially shown in the corner (Windows)
Description
Found this while researching JDK-8090267. While using an IM window inside a JFXPanel the AWT code will call into the InputMethodRequests on the AWT EventQueue thread. These calls are being passed straight into JavaFX on that same thread. As far as I know the InputMethodRequests can only be called safely on the JavaFX thread.

This happens on all platforms but so far I've only been able to create a reproducible case on Windows 11 (I can't test Win10). The two threads are asking the same Text object to layout the glyphs in an interleaved manner.

Steps to reproduce:
- Switch to Japanese in half-width alphanumeric mode (you should see an "A" in the task bar next to the Japanese IM log)
- Run the attached test program
- Press "a" twice
- Switch to Hiragana (click once on the "A" in the task bar)
- Press the "a" key again

Expected results:
- In the text field you should see two "a" characters followed by a Japanese glyph

Actual results:
- The entered text is duplicated, two a's followed by a Japanese glyph followed by two a's and the same Japanese glyph
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jfx/pull/1337 Date: 2024-01-16 17:59:42 +0000
23-07-2024
Changeset: 11706581 Author: Martin Fox <mfox@openjdk.org> Date: 2024-01-23 21:23:22 +0000 URL: https://git.openjdk.org/jfx/commit/11706581053ca3fc38b175882e573858d0d42020
23-01-2024
OK...In that case you can raise a PR once JDK-8221261 is integrated
12-01-2024
The code is in modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java. Every call made on the fxRequests object needs to be wrapped in Platform.runAndWait. I started putting together a pull request for this (repo beldenfox/jfx, branch jfxpanelthread) but ran into the deadlock problem on Mac.
11-01-2024
OK..After lot of tries, I could reproduce..attached is the bug screenshot.. BTW, it was mentioned "fix is to call Platform.runAndWait to execute in the JavaFX thread and return the results"... May I know where exactly it was done as the below change is not fixing it seems @Override protected void processInputMethodEvent(InputMethodEvent e) { + PlatformImpl.runAndWait(() -> { if (e.getID() == InputMethodEvent.INPUT_METHOD_TEXT_CHANGED) { sendInputMethodEventToFX(e); } super.processInputMethodEvent(e); + }); }
11-01-2024
I am not able to reproduce this in my WIndows11..If I type "a" twice in in half-width alphanumeric mode and then Switch to Hiragana and Press the "a" key again I am getting aa followed by Japanese glyph.. This is with latest jdk and latest jfx repo..ATtached is screenshot..
11-01-2024
A new PR for JDK-8221261 which fixes the bug entirely in JavaFX code is now under review. That bug should be integrated before fixing this bug, so I linked this bug as "blocked by" JDK-8221261.
10-01-2024
I can reproduce the bug on my Windows 11 system in both of the two ways you describe. And yes, your analysis is correct. It is effectively the same problem as that fixed by JDK-8196011 and reported in newly-filed follow-on bug, JDK-8322703. The solution is similar, although if we fix this bug without also fixing JDK-8221261, the misbehavior we currently see will turn into a deadlock on macOS.
03-01-2024
I think your analysis is correct, but I'll take a closer look. We ran into similar problems with IME calls in WebView. See JDK-8196011 along with a newly-filed follow-on bug, JDK-8322703. The deadlock on mac is exactly as you describe. See JDK-8221261, for which there is a PR and discussion going on in https://git.openjdk.org/jdk/pull/17184 . I spent some time before the end-of-the-year break looking at a slightly modified version of the proposed solution and will be discussing it with the AWT folks this week.
02-01-2024
You can probably reproduce this on Windows simply by switching to an IM and typing a lot and quickly. Eventually there will be a thread collision. The obvious fix is to call Platform.runAndWait to execute in the JavaFX thread and return the results. This works on Windows but deadlocks on the Mac. On Mac the OS calls are entering AWT on the JavaFX thread (!) then AWT moves them over to its event dispatch thread. Attempting to shift back to the JavaFX thread causes deadlock.
01-01-2024