JDK-8120552 : Fix handling of HitInfo
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-09-10
  • Updated: 2015-06-17
  • Resolved: 2012-09-20
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
Relates :  
Description
In TextFieldSkin#positionCaret the caret position is set to hit.getInsertionIndex(); and the bias to setForwardBias(hit.isLeading());

This is wrong because  hit.getInsertionIndex() already adds one when leading==false, see HitInfo:
public int getInsertionIndex() {
    return leading ? charIndex : charIndex + 1;
}

That means when trailing is true this code will place caret in the trailing edge of the next characters of the hit. 
This only works today because Text does not implement caret bias but that is about to change.

Note also that adding one to charIndex is not 100% correct, it does not work for bidi boundary nor for line end of wrapped lines.

Other problem I have is the doc of caretBias,
currently the code in controls uses caretBias==leading, meaning
caretBias==true, caret at the leading edge of character at charIndex
caretBias==false, caret at the trailing edge of character at charIndex

The doc for caretBias in Text reads:
* caret bias in the content. true means a bias towards forward character


Which makes me think that caretBias==true really trailing (towards the next character)...

In short, the code today does:

text.setImpl_caretPosition(info.getInsertionIndex());
text.setImpl_caretBias(info.isLeading());

But it should be

text.setImpl_caretPosition(info.getCharIndex());
text.setImpl_caretBias(info.isLeading());

or, depending on the definition of caretBias:

text.setImpl_caretPosition(info.getCharIndex());
text.setImpl_caretBias(!info.isLeading());

Comments
SQE verified with 8b86
23-04-2013

Changed the call as suggested: public void positionCaret(HitInfo hit, boolean select) { - int pos = hit.getInsertionIndex(); + int pos = hit.getCharIndex(); There is still a related issue with clicking at the end of a line of wrapped text where there is usually a space. The caret ends up at the beginning of the next line.
20-09-2012

Note, RT-17411 has being pushed to the graphics scrum. You should be able to reproduce the problem on your repo after the next sync up.
11-09-2012

The bug can be reproduced with HelloTextField (using the text sandbox, which is likely being merged this week). steps run HelloTextField increase the font several times (not necessary but makes it easier to see the problem) type a bunch of m or w click on the right side of any char expected result: caret placed on the right side of the clicked character actual result: caret placed on the right side of the character on the right of the clicked character
10-09-2012