JDK-8292933 : Multiple focused components accepting keyboard input
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: jfx11,jfx20
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-08-25
  • Updated: 2024-06-27
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8319317 - Linux: Broken Focus/KeyEvents for TextField when repeatedly displayed in new Stage
Relates :  
JDK-8091670 - Add API for better control over keyboard focus
Relates :  
JDK-8090456 - Focus Management
Description
Two components are focused and accept keyboard input.

To reproduce: 
- click on the text field
- press SPACE
Notice both the text field and the check box have the focus and handle keyboard input.

original report and example
https://github.com/andy-goryachev/JavaBugs/blob/master/src/goryachev/bugs/fx/DualFocus.java
Comments
I guess the expected behavior is for the TextField to lose the focus and not handle keyboard input. It may still display that is has a focus in the main window, albeit inactive (I don't think FX has such a concept yet). So the issue boils down to: - TextField should not show active focus decoration and have input focus - TextField should not handle keyboard input since the popup is focusable and has a component that has input focus. The swing handles a similar situation correctly (see attached DualFocusSwing.java).
18-01-2024
I'm not sure this issue is describing a bug. The key events are going to different windows but that's because the code is using a component (PopupWindow) that splits key events across windows by design. If an app has a menubar and there's an open menu in that bar the two windows each need to handle key events. For example, the menu needs to process up and down arrows while the menubar needs to process left and right arrows. From what I can tell PopupWindow is specifically designed to handle this case; incoming key events are first sent to the popup and then to the owner. This behavior is not documented but it is long-standing and can't be changed.
06-01-2024
Thank you [~mfox] for looking into this issue! While your findings are correct, and the bug can be fixed by consuming all key events by the popup, I think this particular example illustrates a need for some kind of more meaningful focus management in javafx. We see two controls being focused and receiving the events, while in a Swing world only one will be focused.
16-05-2023
The checkbox is inside a popup window which is owned by the main stage. Pressing the Space bar generates two events, a KEY_PRESSED event and a KEY_TYPED event. Here the check box is consuming the KEY_PRESSED event and ignoring the KEY_TYPED event. The KEY_TYPED event is making its way to the owning stage window and being processed by the text field. This is fundamentally an issue with the way key downs generate two separate events, there's always the chance that the PRESSED event will be consumed in one location and the TYPED event in another. This can even create issues within one control. If you're editing text and press Ctrl+A it generates a PRESSED event which invokes Select All and then a TYPED event with the letter "a". The TextInputControl inspects the modifiers on the TYPED event and ignores anything that looks like it's an accelerator.
16-05-2023