JDK-4995931 : java.awt.TextComponent caret position does not follow spec
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2004-02-17
  • Updated: 2017-05-19
  • Resolved: 2006-02-07
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 6
6 b71Fixed
Related Reports
Relates :  
JDK-4939397 - SPEC BUG: java.awt.TextComponent 5 issues
Description
This is an extension of bug 4939397.  I need to file another CCC request and can't because I did under that bug #.

Issue #5 as cited in the original bug report is still not fixed.  See that bug report for further info (cut/paste doesn't work in VNC).
Comments
EVALUATION The JCK team is happy with the current spec: "The caret position is constrained to be between 0 and the last character of the text, inclusive." However, there are cases where a call to getCaret() returns a value outside the bounds [0,text-length]. This can happen when the text is resized and the current caret position is outside the new text size. This behavior should be fixed.
10-11-2005
EVALUATION Unfortunately this bug is not as simple as it seems. Our toolkits differ in behavior. The components also behave in a different way depending on presence of peers. We cannot document this behavior until it is made consistent. The follwing problems were found: 1) The user is allowed to set any invalid caret position when there is no peer. Fixing this may pose a potential compatibility problem. 2) When the peer is created, XToolkit sets the caret position to zero. Other toolkits do not do this. 3) shortening the text by setText sets the cursor position to zero on WToolkit and MToolkit. XToolkit doesn't do that. and there are more incompatibilities... we should sort all them out and probably it's already too late for Mustang.
13-09-2005
EVALUATION 5. expected behaviour for getCaretPosition if text has been changed so the caret position is out of the new text bounds ###@###.### 2004-03-05 =========================================================================== As far as I see this is a spec change. I understand the whole situation with 4982601, 4939397 and this one. But anyway the bottom line is: this spec change is not passed thru the CCC cycle. Thus this is unapproved change so far. Also: the updated spec states: -- cut here -- public int getCaretPosition() ... The caret position is constrained to be between 0 and the last character of the text, inclusive. ... -- cut here -- This quote does not specify the exact expected behaviour if the current size of the text is smaller than the caret position. It does say that "the caret position is constrained" to be within the new text bounds but it does not say the exact position. Every position from [0..newsize()] can be considered "to be constrained". ###@###.### 2004-03-26 =========================================================================== As this bug extends 4939397, I'm reassigning this to the same product/category and manager/engineer. ###@###.### 2005-03-22 14:29:01 GMT This bug was not "not fixed" for lack of trying. Much effort was involved between engineering and documentation. Due to Sun's restructuring, documentation no longer fixes api/spec bugs. This is now owned by engineering (and engineering is required to fix this). Reassigning. ###@###.### 2005-07-15 19:16:51 GMT
15-07-2005