JDK-8130721 : [macos] problem with editing thai in TextArea
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-07-08
  • Updated: 2020-01-31
  • Resolved: 2017-10-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.
JDK 10 JDK 8
10Fixed 8u162Fixed
Related Reports
Duplicate :  
This happens with Mac OS X 10.10 only. In a TextArea, setWrapText(true), then input thai characters. The line wrap is not working as expected. Some lines have only 1 character. Please find the attached video.
Confirmed that the patch applies cleanly.

Patch provided for 10-dev applies cleanly to 8u-dev. There is no difference other than file path ("javafx.graphics" folder is now "graphics"). I have created a webrev for 8u-dev ( http://cr.openjdk.java.net/~dkumar/8130721/webrev.02/ ). I have tested the fix with the given test program (HelloText) and HelloTextArea sample with different character sets (Arabic, Japanese, Korean, Thai and English) and test results are fine. Unit test run with the fix (:controls:test :graphics:test) is fine.

This is approved to backport to 8u-dev for 8u172. If the patch applies cleanly (after adjusting the file path), then please indicate this, otherwise, please provide a webrev against FX 8u-dev. In either case, please test this with 8u and indicate the results of this testing.

Changeset: 37c3267e3a01 Author: dkumar Date: 2017-10-23 11:08 -0700 URL: http://hg.openjdk.java.net/openjfx/10-dev/rt/rev/37c3267e3a01 8130721: [macos] problem with editing thai in TextArea Reviewed-by: kcr, prr



Thanks [~kcr], [~prr] for reviewing the code changes. I have incorporated the review comments. Please find the updated webrev at http://cr.openjdk.java.net/~dkumar/8130721/webrev.01/ and let me know your inputs.

Looks reasonable. I suspect this may be affecting other scripts but CoreText docs don't explain when it will return NULL. Apart from the change required by Kevin, I also ask that you check for a NULL return from malloc

Phil will also need to review this. My only comment is that it is probably best to check for count == 0 and return 0 immediately, rather than allocating a 0 element array (which is allowed to return NULL), and then calling CTRunGetStringIndices with that possibly-null array and 0 count.

Webrev: http://cr.openjdk.java.net/~dkumar/8130721/webrev.00/ Please refer to above comment for fix explanation. I have tested the fix with the given test program and HelloTextArea sample with different character sets (Arabic, Japanese, Korean, Thai and English). Unit test run (:web:test :controls:test :graphics:test) is fine.

Problem seems to be in Coretext JNI layer. To retrieve the char indices stored in the text run, one of Coretext API "CTRunGetStringIndicesPtr" is being used. This API returns NULL for Thai characters and this case has not been handled. Coretext Apple documentation clearly says that this function can return null even for valid stream and an alternative approach has to be taken. Excerpt from the API documentation of CTRunGetStringIndicesPtr [1]- "The caller should be prepared for this function to return NULL even if there are glyphs in the stream. If this function returns NULL, the caller must allocate its own buffer and call CTRunGetStringIndices to fetch the indices." I tried quickly a fix based on above approach and observed that wrapping of Thai characters is fine. Tests with other character sets (Arabic, Japanese, Korean and English) are also fine. [1] https://developer.apple.com/documentation/coretext/1510605-ctrungetstringindicesptr?language=objc

This is also broken on Mac OSX 10.12 (not just 10.10)

Reproduced with 8GA .. moving to nicetohave Note it does also appear to be Mac-specific.

Here is a small test app without any controls code (just a Text node): import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.VBox; import javafx.scene.text.Text; import javafx.stage.Stage; public class HelloText extends Application { public static void main(String[] args) { Application.launch(args); } @Override public void start(Stage stage) { final Text text = new Text("������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������"); text.setWrappingWidth(300); Scene scene = new Scene(new VBox(text), 300, 800); stage.setScene(scene); stage.show(); } }

What about 8 GA ? setWrapText is a control UI .. also this seems to be when editing (input methods) unless this is reproduced with the Text node it belongs to one of those.

No, it not a regression. It's reproducible in 8u45. I didn't try other releases.