JDK-8136838 : [ComboBox, DatePicker] Value doesn't update when focus is lost
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8u60
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-09-21
  • Updated: 2020-01-31
  • Resolved: 2015-10-02
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 JDK 9
8u72Fixed 9Fixed
Related Reports
Duplicate :  
JDK-8140502 - ComboBox value should update when focus leaves it
Duplicate :  
JDK-8144499 - DatePicker does not update value if entered in textField
Duplicate :  
JDK-8092295 - [ComboBox, DatePicker] The DatePicker does not update its value on focus lost, and there is no way to force an update.
Relates :  
JDK-8151129 - Editable ComboBox value update on focus lost is too late
Relates :  
JDK-8191995 - Regression: DatePicker must commit on focusLost
Description
Run HelloComboBox or HelloDatePicker. Type some valid text followed by Tab. The new value remains in the text field, but it is not committed.

This is a regression caused by fix for JDK-8096725, which broke the fix for JDK-8120120.
Comments
Approved to backport to 8u-dev.
08-10-2015
Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/e667f5baecfd
02-10-2015
+1
01-10-2015
Webrevs for review: http://cr.openjdk.java.net/~leifs/8136838/webrev-8u.00/ http://cr.openjdk.java.net/~leifs/8136838/webrev-9.00/ The fix restores the focus listener and focus outline that were lost with JDK-8096725.
01-10-2015
thanks for filing this! Regarding the other two (mine :) workarounds: - using a custom skin - even if it requires access to internal api - has the advantage of using them via a styleSheet, that is once in an application (well, not entirely, with StyleManager being internal as well, it would be once per scene/window/popup) vs. for each combo/datePicker individually - the other one was more like playing with TextFormatter, it's (missing) integration to all controls that have textual input that can be committed to a value is another, though related, issue Thanks Jeanette
23-09-2015
It's probably safe to call setValue twice. It's a final method, so there shouldn't be any surprise overrides.
22-09-2015
Are there known side-effects of calling setValue twice? If the value is the same both times I figured the second call would not have any effect.
22-09-2015
That looks like a better workaround than the ones at stackoverflow��. You may want to check the new value against the current to see that it hasn't been set already, just to avoid any side effects of calling setValue twice. �� https://stackoverflow.com/questions/32620739/java-8-datepicker-and-editable-combobox-behavior-change-between-8u51-and-8u60
22-09-2015
I've currently got this workaround in place in the latest app I've been working on. (If there is a better one, please share.) I just didn't want to have to hack a bunch of older code to workaround it there as well. I'm also concerned about the side-effects when this issue is properly fixed and this hacked code is still out there. combo.getEditor().focusedProperty().addListener((obs, old, isFocused) -> { if (!isFocused) { combo.setValue(combo.getConverter().fromString(combo.getEditor().getText())); } });
22-09-2015
Sorry, no chance for 8u66. We'll get it into 8u72.
22-09-2015
This is a fairly serious issue that's really going to confuse our customers. Is it possible to make it into 8u66?
22-09-2015
@Leif: can you think of an app level workaround for this bug?
22-09-2015