Behavior of TitledPane concerning the ENTER key and focus

Keimel, Christoph c.keimel at
Thu Mar 19 08:53:32 UTC 2015


I would like to address two difficulties we are having with TitledPane:
- TitledPaneBehavior sets up a KeyBinding for ENTER to trigger the TitledPane to toggle its expanded property. (Issue A)
- TitledPane accepts the focus even when is not collapsible (Issue B)

*** Why I would like to change this ***

The main issue with (A) is that TitledPane and default buttons don’t work well together. Regardless of where the default button is in the scene, it can’t be fired by pressing ENTER anymore as soon as the focus is on any control which is a descendent of a TitledPane. A similar bug has been reported concerning the ComboBox [1].

We are currently migrating a government application to JavaFX (on Windows). The user interface layout has been designed with the tool wxDesigner. These declarative ui design files are currently transformed to FXML on the fly and then loaded. (Once the migration is complete SceneBuilder will be used to work on FXML directly). So we have no control over the layout of the ui. The designers really like to use the windows group box to create labeled sections inside of their (potentially very large and complex) forms to give them a better structure (recommended by the accessibility guidelines). The closest thing to the group box concept in JavaFX is the TitledPane. 

The designers also like to have a default button in every window (a soft requirement of the accessibility guidelines). Since almost all input controls are somehow a descendent of a TitledPane (which are even nested sometimes) the default button is effectively not accessible with ENTER during input. This will be treated as a Regression by our customer, so we somehow have to make it work. 

The fact that TitledPane accepts the focus even when it is not collapsible (B) is a different, minor issue. The problem here is that the focus is not visible when it is on the TitledPane, because the “toggle button” of the TitledPane is not visible. This violates a soft requirement of the accessibility guidelines.

[1]: [Default Button] Button set to default is not reacting ComboBox enter key -

*** My technical understanding of A ***

The ENTER key is registered as a KeyBinding to toggle the expanded property of TitledPane. The key biding is always set in the constructor of TitledPaneBehavior independent of the properties of the TitledPane. If a key binding is registered for a KeyEvent, then this event will be consumed in the bubbling phase (independent of any action actually being executed).

The default button registers an accelerator for ENTER with the Scene. The accelerator is activated for the KeyEvent ENTER when the event bubbling reaches the scene only if the event has not been consumed during event processing.

*** Considerations to A ***

Looking at it from an “accessibility” point of view, one key binding is enough. TitledPane also registers the SPACE key to toggle its expanded state. This is consistent with other controls like Button, CheckBox, RadioBox. From my point of view, the small triangle on the top left corner of the TitledPane is pretty much like a button, so this makes sense. Do we need the additional ENTER key binding?

Ok, let’s assume we do. In that case the KeyEvent for ENTER should only be consumed, if it is actually handled by the control (when the toggle is performed). This will only be the case if the TitledPane is collapsible and has the focus. Currently the KeyEvent is always consumed when it passes through TitledPane by the default implementation of BehaviourBase.callActionForEvent regardless of whether it actually triggers an action or not.

*** Conclusion ***

The direct approach to (A) could be to override BehaviourBase .callActionForEvent in TitledPaneBehaviour to customize the event consummation. A general approach might be to extend the API of BehaviourBase, so that events are not necessarily consumed when the key binding does not really fire an action. I see that there is some reconstruction underway in this area with RT-21598 [2].

But from my point of view the simplest thing to do would be to drop the key binding for ENTER in TitledPane all together, which I would like to hereby propose (Solution A-II). 

To fix the minor issue of the hidden focus (B) it should be enough to bind the TitledPane.focusTraversableProperty to TitledPane.collapsibleProperty.

[2]: Move BehaviorBase into public API -

*** Next steps ***

I am unsure of the next steps to take. Does it make sense to create issues for A and B? (Sorry for creating RT-40166 [3] prematurely.)

Does it make sense to start to work on these issues, or will this be resolved in the course of the work on RT-21598 [2]?


*** Workaround ***

In the meantime I am using a workaround to customize all TitledPanes after loading the FXML which above. 

The code can be viewed here: TitledPaneCustomizer [4]
With a small test case here: TitledPaneTest [5]


Thanks for your attention.

Christoph Keimel
Oskar-Messter-Straße 29 
85737 Ismaning 

Tel: 089 / 996547-26 
Fax: 089 / 996547-99 
E-Mail: c.keimel at
Geschäftsführer: Dipl.-Inf. (FH) Georg Engl UST-Id-Nr.: DE 131 175 644, HRB 80271 München

More information about the openjfx-dev mailing list