JDK-8127975 : TextField : the text sometimes disappear
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 7u6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-04-10
  • Updated: 2015-06-17
  • Resolved: 2012-04-13
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 7
7u6Fixed
Related Reports
Duplicate :  
JDK-8127037 - TextField: text disappears after being selected and then clicked.
Relates :  
JDK-8112747 - Render tree is modified during Text bounds calculation
Relates :  
JDK-8127037 - TextField: text disappears after being selected and then clicked.
Description
Launch the attached test case.
Select all the text of the first TextField.
Click on the TextField : the text disappear...
 It is displayed again if one click in another TextField.
Comments
verified in b10
30-05-2012
I've filed another CR for this: RT-21092 It might be duplicate, but might also contain something useful.
24-04-2012
I think this comes down to not copying across the selection changes to the NGTextHelper used by the NGText node. This is because we clear the dirty bits when we sync. down to the NGTextHelper used internally by the public API Text node. If nothing else happens to cause the node to be synced, we don't flush the state until such an event does happen. Things are then *not* in sync! The minimal fix appears to be to add a new dirty bit "TEXT_HELPER" which indicates that the helper needs to be synced across. This is set when ever any state is copied to the helper and its specific dirty bit cleared, for example the TEXT_SELECTION bit. I think we do want to be doing the clearing of these individual bits or we could be doing wasted work. The TEXT_HELPER bit should not lead to extra work except in cases like this that are broken. This does resolve the test case provided.
11-04-2012
It seems there was a further regression some time later, where the highlight color is no longer set to white initially. It will turn white after some manipulation of the caret and selection. I have not been able to track this down to a particular changeset, other than that it appeared after the merging of rt-closed: 5596d22c3ea6, and rt: 1ba55d2ecc03.
10-04-2012
This appears to be a regression caused by the fix for RT-13735. The Text node now doesn't set the text fill color back from white to black after the selection is cleared. The bug is reproducible with promoted build 2.2 b03, but not with b02.
10-04-2012
We get this issue in other test cases, and in SceneBuilder. It is always related to selection, but sometimes appear when the arrow keys are used.
10-04-2012