JDK-8115439 : TextField/TextArea: on Windows, for Thai text, caret goes back to the beginning when it meets "���" character.
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-09-05
  • Updated: 2015-06-17
  • Resolved: 2013-10-18
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 8
8Fixed
Related Reports
Blocks :  
JDK-8092327 - [Text] Add API to count chars in a cluster
Blocks :  
JDK-8123381 - TextField/TextArea: on Windows, ArrayIndexOutOfBoundsException for complex Thai characters.
Duplicate :  
JDK-8123266 - Text field selection is incomplete with arabic symbols
Description
This is reproducible after RT-26250 got fixed. When typing arrow keys, the caret goes back to the beginning of the string when it meets "���" character. Here "���" is combined with other characters, for example: "���������" , "������", "������", "������".

The similar issue happens for Hindi. But I could not recognize which characters cause the problem for Hindi.
Comments
Verified fix in b113. The remaining issue is filed as RT-33828.
25-10-2013
Please file a new bug for platform aware cursor navigation (target version Van Ness). Thank you.
18-10-2013
I talked to Leif yesterday about this problem. To see the problem we had to change the text in the sample from "\u0E23\u0E33" to "-\u0E23\u0E33-", where the ouput becomes: pos = 0, path = MoveTo[x=0.0, y=-12.94921875] LineTo[x=0.0, y=3.01171875] pos = 1, path = MoveTo[x=4.798828125, y=-12.94921875] LineTo[x=4.798828125, y=3.01171875] pos = 2, path = MoveTo[x=0.0, y=-12.94921875] LineTo[x=0.0, y=3.01171875] pos = 3, path = MoveTo[x=15.41015625, y=-12.94921875] LineTo[x=15.41015625, y=3.01171875] pos = 4, path = MoveTo[x=20.208984375, y=-12.94921875] LineTo[x=20.208984375, y=3.01171875] Where that x=0.0 for pos = 2 is the problem that is moving the caret to the beginning of the line. I have a (easy) fix that will change that output to: pos = 0, path = MoveTo[x=0.0, y=-12.94921875] LineTo[x=0.0, y=3.01171875] pos = 1, path = MoveTo[x=4.798828125, y=-12.94921875] LineTo[x=4.798828125, y=3.01171875] pos = 2, path = MoveTo[x=4.798828125, y=-12.94921875] LineTo[x=4.798828125, y=3.01171875] pos = 3, path = MoveTo[x=15.41015625, y=-12.94921875] LineTo[x=15.41015625, y=3.01171875] pos = 4, path = MoveTo[x=20.208984375, y=-12.94921875] LineTo[x=20.208984375, y=3.01171875] That is not perfect cause it will take two strokes to move the caret over the cluster (first stroke does not move the caret). The ideal solution is that the caret is never placed on pos = 2, as Windows doesn't like that. But that fix will require better integration between control and graphics (and I don't see that happening for 8). Note: Currently Controls uses BreakIterator which says is pos = 2 is a valid tab stop (and that is consistent with Mac, but not on Windows).
17-10-2013
We need RT-26961 to be implemented for this.
04-10-2013
How can we detect this situation? It seems that BreakIterator sees this as two separate characters. We'd need to add conditionals in the TextInputControl.forward() and in HitInfo.
04-10-2013
DirectWrite returns a cluster map of [0,0] for the text "������". Which means both chars map to the first glyph (in the glyph cluster) This is consistent with Windows, paste the text in the description "���������" , "������", "������", "������" in notepad to note that a single arrow key move the caret over the entire cluster. Thus, it is not possible to place the caret in the middle of the, for example, "������". Also note that the delete key, when place in front of the cluster, deletes the entire cluster in one hit. In the other hand, the backspace key, when place after the cluster, will delete a single character from the cluster. That is correct behavior on Windows. The result for the given program is correct, but keep in mind that "pos = 1" is not a valid caret stop on Windows. Leif, should I reassign this bug jira back to you ?
03-10-2013
The attached test case RT32717.java sets the caret position on a Text node with the string "������", and then asks for the caret path. Ubuntu 13.04: pos = 0, path = MoveTo[x=0.0, y=-12.06689453125] LineTo[x=0.0, y=3.06591796875] pos = 1, path = MoveTo[x=7.2998046875, y=-12.06689453125] LineTo[x=7.2998046875, y=3.06591796875] pos = 2, path = MoveTo[x=14.47265625, y=-12.06689453125] LineTo[x=14.47265625, y=3.06591796875] Windows 7: pos = 0, path = MoveTo[x=0.0, y=-12.94921875] LineTo[x=0.0, y=3.01171875] pos = 1, path = MoveTo[x=0.0, y=-12.94921875] LineTo[x=0.0, y=3.01171875] pos = 2, path = MoveTo[x=10.96875, y=-12.94921875] LineTo[x=10.96875, y=3.01171875]
28-09-2013
This is duplicated by RT-32623, which has the same issue with overlapping Arabic characters.
18-09-2013
Not reproducible on Linux.
12-09-2013
On Windows, this issue might be mixed up with RT-32705. So attached a program for Hindi. Please try it on Mac, which doesn't have RT-32705, but the caret issue is reproducible. When pressing Right key, the caret doesn't always move to right. (There is not any bidi text in the string.)
05-09-2013