JDK-8195675 : Call to insertText with single character from custom Input Method ignored
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8u151,10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2018-01-16
  • Updated: 2025-01-30
  • Resolved: 2024-05-28
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 11 JDK 17 JDK 21 JDK 23
11.0.27-oracleFixed 17.0.14Fixed 21.0.6Fixed 23 b25Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
I don't have java installed to run at the command line. OmegaT reports that it is running on Java 1.8.0_144 (64-bit). jEdit reports that is using Java 1.8.0_151 (which I downloaded directly, independent of jEdit).

ADDITIONAL OS VERSION INFORMATION :
macOS 10.12.6 (16G1114)

EXTRA RELEVANT SYSTEM CONFIGURATION :
I am reporting behavior observed in both OmegaT and jEdit (see version info).

Here is the original bug report filed with OmegaT: https://sourceforge.net/p/omegat/bugs/889/

A DESCRIPTION OF THE PROBLEM :
Using the Keyman (Keyman.com) ISIS-Devanagari keyboard, I expected to be able to type the letter "j" and see ज, but instead I just got a plain "j". Typing a subsequent "i" does insert the correct two-character sequence (जि), but it fails to delete and replace the errant "j" character. I have written a small test input method to reproduce this with a minimum of code, and it appears that the problem is calling insertText: and passing a single character as the string to insert). If I pass two ज characters or a space followed by a ज, it outputs just fine. I also tested this with a simple Roman script letter using a test case where typing the letter "l" was supposed to produce a "j" and that also failed. If you don't want to download and use Keyman to reproduce this, I would be happy to provide my simple test IM.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
To reproduce using Keyman:
1) Download and install Keyman for macOS from https://keyman.com/macos/
2) Follow instructions to install Keyman and set it up as an Input Method: https://help.keyman.com/products/mac/1.0/docs/start_download-install_keyman.php?_ga=2.174123428.780044351.1516121660-886959843.1497845253
3) Follow instructions here to download and install a keyboard: https://help.keyman.com/products/mac/1.0/docs/start_download-install_keyboard.php. Download and select the ISIS-Devanagari keyboard as the keyboard for Keyman to use.
In OmegaT, jEdit, or any application that uses the text editor in JDK, type a "j".

If necessary, I can provide a very simple test IM that will illustrate the problem without requiring the above steps, but since Keyman is already packaged up nicely for easy installation, this is probably the easiest way to reproduce.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You should get a ज character. (Furthermore, typing a subsequent "i" should replace the ज with जि. However, this could require some more work on our end because many "legacy" apps that don't use Apple's editing controls require a special mode in Keyman to correctly handle character replacements.) You can observe the correct behavior of the keyboard in any standard Apple app, such as Notes or Messages.
ACTUAL -
Outputs a plain "j" character.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
The only workaround I know of would be to type the text in another application and paste it into the application that uses the JDK editor.

Note that this deficiency is not directly hampering the development of Keyman (which has been chosen as the software to serve as the official reference implementation for the LDML standard). It does, however, affect all of any software whose editing is based on this JDK editing control. Although OmegaT declined to follow up on this directly, they do have affected users. I don't know of any existing users complaining about jEdit or any other software that uses this control, but there may well be some.


Comments
[~sgehwolf] thanks- somehow i missed that the 11 one was ready!
30-01-2025

[~srl] https://github.com/openjdk/jdk11u-dev/pull/2954 is ready for integration. Type /integrate? The JDK 8u PR needs a review from an SME first.
30-01-2025

[~sgehwolf] hi - can you help me with getting this into OpenJDK 8 and 11? This really impacts minority language users trying to type in Java apps.
30-01-2025

[~srl] I will integrate the fix into Oracle JDK 8 and 11. [~sgehwolf] Can you please help with approval for integration into OpenJDK 8 and 11?
08-01-2025

[~dmarkov] thanks- is it possible to get a triage for Java 8 and 11?
08-01-2025

Ping, any way to get the 8 and 11 request checked?
29-11-2024

Update: I have verified this fix in all four open PRs - 8, 11, 17, 21, as well as verifying that current nightly downloads of v23 already have the fix. Typing `ji` - `naan` - `kala` produces the expected text in JEdit (जि-नाअन-काला) in all four PRs, plus in the current versions of 23 (which already have the fix merged) Please consider these fixes.
25-10-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/2971 Date: 2024-10-17 13:17:40 +0000
17-10-2024

[jdk17u-fix-request] Approval Request from Steven R. Loomis java.awt components did not work properly on macOS with custom input methods, the net effect is that minority language keyboards did not work properly with Java. Low risk, the fix handles this situation similarly to how Apple's own 'kotoeri' input method was handled on a long term basis, so it is a well-worn path. Patch should apply cleanly and was code reviewed
17-10-2024

[jdk11u-fix-request] Approval Request from Steven R. Loomis java.awt components did not work properly on macOS with custom input methods, the net effect is that minority language keyboards did not work properly with Java. Low risk, the fix handles this situation similarly to how Apple's own 'kotoeri' input method was handled on a long term basis, so it is a well-worn path. Patch should apply cleanly and was code reviewed
16-10-2024

[jdk17u-critical-request] Approval Request from Steven R. Loomis java.awt components did not work properly on macOS with custom input methods, the net effect is that minority language keyboards did not work properly with Java. Low risk, the fix handles this situation similarly to how Apple's own 'kotoeri' input method was handled on a long term basis, so it is a well-worn path. Patch should apply cleanly and was code reviewed
16-10-2024

[jdk8u-fix-request] Approval Request from Steven R. Loomis java.awt components did not work properly on macOS with custom input methods, the net effect is that minority language keyboards did not work properly with Java. Low risk, the fix handles this situation similarly to how Apple's own 'kotoeri' input method was handled on a long term basis, so it is a well-worn path. Patch should apply cleanly and was code reviewed
16-10-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk11u-dev/pull/2954 Date: 2024-10-16 20:22:48 +0000
16-10-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk8u-dev/pull/595 Date: 2024-10-16 20:19:03 +0000
16-10-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u/pull/403 Date: 2024-10-16 19:52:36 +0000
16-10-2024

Fix Request java.awt components did not work properly on macOS with custom input methods, the net effect is that minority language keyboards did not work properly with Java. Low risk, the fix handles this situation similarly to how Apple's own 'kotoeri' input method was handled on a long term basis, so it is a well-worn path. Patch should apply cleanly and was code reviewed. Fix in v23: https://github.com/openjdk/jdk/pull/17921
16-10-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/1052 Date: 2024-10-14 16:43:35 +0000
14-10-2024

[~aivanov] it's already in 23u - the original PR was merged in May. - https://github.com/openjdk/jdk23u/commit/b8f2ec9091f9f7e5f4611991d04dd8aa113b94fd
14-10-2024

[~srl] You should not skip backporting to 23u. Thus, you should backport to 23u (jdk23u repo) before you backport to 21u or any previous LTS. You do not need to create a backport record in advance unless you really have to do it for whatever reason. Let the Skara bot which handles integration create it for you. Here's a quote from https://openjdk.org/guide/#working-with-backports-in-jbs “In general there’s no need to create backport issues in JBS manually. All work that’s done in JBS in preparation for a backport (requesting approvals etc) is done in the main issue. The backport issue will be created automatically by the bots when you integrate the change to the source code repository.”
14-10-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/17921 Date: 2024-02-20 02:08:09 +0000
14-10-2024

Changeset: b8f2ec90 Author: Steven Loomis <srl@openjdk.org> Date: 2024-05-28 16:44:44 +0000 URL: https://git.openjdk.org/jdk/commit/b8f2ec9091f9f7e5f4611991d04dd8aa113b94fd
28-05-2024

Comparing to <https://keymanweb.com/#hi,Keyboard_isis_devanagari> it seems that the sample text should produce: ज जि नाअम काला
19-03-2024

I'm trying an experimental branch at https://github.com/srl295/jdk/tree/jdk-8195675/keyman
16-01-2024

It was pointed out that Kotoeri is obsolete and could be removed from the special case code.
31-10-2023

Thanks for offering to look at this.
31-10-2023

Reproduced the issue with JDK 10 on Mac OS Sierra 10.12.6. Typing "j" on JEdit displays j Typing "ji" on JEdit displays jजि Typing "naam" on JEdit displays nनाam Typing "kala" on JEdit displays kकाlला
30-01-2018

Reported with: JDK 8u144, 8u151 MAC OS X 10.12.6 Call to insertText with single character from custom Input Method ignored Bugreport filed with OmegaT abd jEdit: https://sourceforge.net/p/omegat/bugs/889/ Checked this with: JDK 8u162, 10 ea b39 MAC OS X 10.13.2 jEdit The issue is reproducible when checked with jEdit following steps from the description: To reproduce using Keyman: 1) Download and install Keyman for macOS from https://keyman.com/macos/ 2) Follow instructions to install Keyman and set it up as an Input Method: https://help.keyman.com/products/mac/1.0/docs/start_download-install_keyman.php?_ga=2.174123428.780044351.1516121660-886959843.1497845253 3) Follow instructions here to download and install a keyboard: https://help.keyman.com/products/mac/1.0/docs/start_download-install_keyboard.php. Download and select the ISIS-Devanagari keyboard as the keyboard for Keyman to use. In OmegaT, jEdit, or any application that uses the text editor in JDK, type a "j". The Keyman with ISIS-Devanagari keyboard works fine in general applications on MAC OS X, for example with TextEdit, however it does failed to work with jEdit. This looks like an issue limited to 3rd party.
18-01-2018