JDK-8115009 : Regression: issue with ComboBox focusedProperty
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-04-19
  • Updated: 2024-07-26
  • Resolved: 2013-09-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
8Fixed
Related Reports
Relates :  
JDK-8092563 - [DatePicker] Pop-up window should open on ALT-UP/DOWN Arrow
Relates :  
JDK-8337246 - SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed
Description
- Start the attached test case.
comBox1 should have the "got the focus" message on start.

- Click on the comBox1 menu button
we should not have any message

- Click in the 2nd ComboBox text field
we should have a "lost the focus" message

This test case is working fine with Fx 2.2.4
Comments
Verified on 8.0b114
05-11-2013
I've developed a fix for this new regression. I just need to apply the same fix for DatePicker and write some more tests, but I will try to get this done before integration this week.
02-09-2013
Unfortunately this fix is incomplete: whilst it resolves the issue identified in the bug report (about clicking on ComboBox text fields), it introduces another issue (tabbing into editable ComboBox does not give the textfield input focus whilst keeping focus on the ComboBox). In other words, the ComboBox has focus as expected now, but unfortunately this means that text input into the TextField doesn't work in the tab case.
02-09-2013
I've resolved this issue for ComboBox and DatePicker, although ideally this fix would be temporary and be backed out once subfocus is supported.
28-08-2013
Fake focus was removed due to the issue identified in RT-24744. I essentially restructured the ComboBox to prevent the button overlapping the TextField, and this required a change to the CSS and focus code. I can't recall if the caret showed with fake focus enabled.
28-08-2013
Was the fakefocus textfield removed just to get the caret working, or were there other issues too? Subfocus wasn't planned for Lombard, and yet this is targeted at lombard, so I'm keen to know why the previous method was abandoned.
28-08-2013
Yes, this is the problem. What I'm hoping for is that the focus system can evolve in some way to support proper subfocus, so that whilst the ComboBox is the focus owner, it can delegate focus to the TextField so that it accepts input and shows the caret.
27-08-2013
ComboBox calling requestFocus() on the inner TextField means that if an app calls requestFocus() on a ComboBox, and then checks the focus owner, it'll find that the focusOwner is the textfield, Also a listener on the ComboBox will get focusGained, followed by focusLost. Is this ok? The description seems to suggest that this might be the problem.
27-08-2013
The issue is that you want the ComboBox to have the focus rect around it but that text input be delivered to the TextField within it. Additionally, you want to have the TextField caret blinking as expected. The current approach is to forward focus to the TextField and fake the focus rect around the ComboBox. This means that the ComboBox never has real focus.
27-08-2013
When I run the testcase I don't get the exact sequence in the description, but nevertheless keyboard navigation for ComboBox does seem broken. This change looks like it could have been caused by the requestFocus() call insert during the switch from the fakefocus TextField. A successful call to requestFocus() on another node will result in the loss of focus for the current node. Is the goal here to maintain focus with the ComboBox, or simply to have correct keyboard navigation?
27-08-2013
@Mick: Do you have any thoughts on this issue?
27-08-2013
The crux of the issue is that an editable ComboBox, when given focus, simply forwards that on to the TextField within it. Unfortunately this means that the ComboBox is no longer considered to be focused, when in reality it appears that way (due to some crafty CSS), and its child is the true focus owner. I think we need some form of subfocus support so that we can keep the ComboBox as the focus owner, but allow it to enable the internal TextField to also be focused (so that text input goes to it and it shows the blinking caret). I've CC'd Mick to get his opinion on this.
09-07-2013