JDK-6866784 : Shift-Tab may cause skipping of a subsequent key event
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • CPU: generic
  • Submitted: 2009-07-30
  • Updated: 2018-09-05
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
Description
The issue has been reported at ###@###.### by ###@###.###

If you have two text fields on a frame, the second
of which is setFocusTraversalKeysEnabled(false), then typing Shift+Tab
in the first field and then any letter will swallow that letter. This
is because the DefaultKeyboardFocusManager sets the
consumeNextKeyTyped flag on the Shift+Tab, which then suppresses the
next KEY_TYPED. Since the KEY_TYPED for Shift+Tab is missing, it
swallows the next normal key.

Comments
- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

EVALUATION The reason of the bug is that consumeNextKeyTyped is reset on KEY_PRESSED only with focusedComponent.getFocusTraversalKeysEnabled() of true. The latter check, though, looks unjustified. That is, the flag should be reset on KEY_PRESSED independently of whether focus traversal keys are enabled or not. So, the code should look like this: public void processKeyEvent(Component focusedComponent, KeyEvent e) { <...> if (e.getID() == KeyEvent.KEY_PRESSED) { // reset the flag consumeNextKeyTyped = false; } if (focusedComponent.getFocusTraversalKeysEnabled() && !e.isConsumed()) { <...> if <FORWARD TRAVERSAL KEYS> { consumeTraversalKey(e); // raise the flag again if (contains) { focusNextComponent(focusedComponent); } return; } <...> if <BACKWARD TRAVERSAL KEYS> { consumeTraversalKey(e); // raise the flag again if (contains) { focusPreviousComponent(focusedComponent); } return; } <...> } }
30-07-2009

EVALUATION Another note by ###@###.###: While investigating this, I also wondered about the fix for bug 6637607, which is mentioned in DefaultKeyboardFocusManager.processKeyEvent(). It looks very asymmetrical, the else only being present on the FORWARD case, but not on the subsequent, basically copy-pasted blocks. Shouldn't one always reset consumeNextKeyTyped right at the start of the if-block? Like so: if (focusedComponent.getFocusTraversalKeysEnabled() && !e.isConsumed()) { consumeNextKeyTyped = false; or maybe like so: if (focusedComponent.getFocusTraversalKeysEnabled() && !e.isConsumed()) { if (e.getID() == KeyEvent.KEY_PRESSED) consumeNextKeyTyped = false;
30-07-2009