Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8131666

Accelerators must fire always, unless key combination is explicitly handled by Control



    • Bug
    • Resolution: Unresolved
    • P4
    • tbd
    • 8u45
    • javafx
    • None
    • JDK 8u45, Win 7 Pro SP1, 64 Bit

    • x86_64
    • windows_7


      Given a dialog having a "Help" button and a TextField, where the "Help" button is registered with the "F1" key combination in the scene's accelerator table, what people are used to is that pressing the "F1" key will show some helpful information, whether the TextField is focused or not.

      This is what happens with native dialogs on the Windows platform, and presumably on other platforms, too. Unfortunately, the JavaFX platform behaves differently: The "F1" key has no effect once the TextField is focused. Not only this is annoying and counterintuitive, it also is inconsistent, as this effect only happens with text input controls. If we change the example a bit, we can find other combinations of focused controls and registered accelerators, which will ceise to fire. For example, a TextField even consumes the ENTER key so a dialog's default button will be "dead" until the focus is moved.

      It is certainly valid behaviour that a control (or to be more precise: a skin) overrides behaviour of key combinations, but this should obviously be limited to key combinations which are actually handled by the control. In our example, there is no purpose in consuming the "F1" key, as a TextField does not use this key for anything at all. Hence, the result when an accelerator is working and when is not, is completely weird and not intuitive: Users simply do not understand why e. g. "F1" is not working on TextFields, as just "nothing" happens which looks like a "broken" key.

      Hence I'd like to suggest checking the key handling of all controls and reduce the consumption of key events to only those which have an actual effect -- at least for Scene-registered accelerators. I have rated this issue as a bug with P3 priority, because the use of accelerators is completely flawed due to this issue, and the only workaround will be to not use the accelerators table at all but instead process key combinations manually on the scene level, which is a mess and leads to heavily unstructured code.


        Issue Links



              Unassigned Unassigned
              mkarg Markus Karg
              0 Vote for this issue
              5 Start watching this issue