JDK-4199622 : RFE: JComboBox shouldn't sending ActionEvents for keyboard navigation
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.2.0,6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_nt,windows_xp
  • CPU: x86
  • Submitted: 1998-12-23
  • Updated: 2017-05-16
  • Resolved: 2013-02-07
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.
7u40Fixed 8Fixed
Name: dbT83986			Date: 12/23/98

When the user pops up a JComboBox (hits the
spacebar for Metal L&F), and then tries to
navigate with the arrow keys, any ActionListeners
for that CB will have their actionPerformed
methods called, and there isn't any information in
the given ActionEvent to show that this was only a
navigation action rather than a selection
(spacebar) action.


import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class inc37498 extends JFrame
 public inc37498()
 	 try {UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel"); }
 	 catch (Exception e) {System.out.println("L&F error"); }
 	 String[] items = {"Item 1", "Item 2", "Item 3", "Item 4", "Item 5"};
 	 JComboBox cb = new JComboBox(items);
	 cb.addActionListener(new ActionListener() {
	    public void actionPerformed(ActionEvent e) {
	      if (e.getID() == ActionEvent.ACTION_PERFORMED) {
	        System.out.println("CB action performed:" + e);
	      } else {
	        System.out.println("CB action:" + e);
 public static void main(String[] args)
 	new inc37498().show();
(Review ID: 37498)
###@###.### 10/12/04 18:24 GMT

EVALUATION Low priority bug - decommitted from JDK7

EVALUATION Just to record my thoughts: 1) We definitely need to change things such that navigating within the popup doesn't send action events until the popup is unposted. This includes both when used with Metal L&F and when the popup is shown with ALT+Down in Windows. 2) Additionally, I'd like to see a property added to JComboBox to control whether or not it behaves like a Windows or Metal combobox in response to the down arrow. Metal posts the popup whereas most Windows comboboxes don't. However, some Windows comboboxes do post popups on the down key. As such, the need for a property.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang

WORK AROUND Name: dbT83986 Date: 12/23/98 I could trap KeyEvents and set a flag each time an arrow key was pressed, unsetting the flag after it was released, and not perform my "selection action" if the flag is currently set. ====================================================================== Serious Hack Alert: What is desired is for the JComboBox to behave like its a table cell editor. Starting with 1.4, the indication that the combo is in a JTable context is provided by the boolean client property "JComboBox.isTableCellEditor". See DefaultCellEditor(JComboBox). You can spoof the JComboBox to make it behave like it's in a JTable by setting the client property for each JComboBox: comboBox.putClientProperty("JComboBox.isTableCellEditor", Boolean.TRUE); You would have to add an actionListener to the combo box to manually hide the combo popup: comboBox.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) { JComboBox combo = (JComboBox)evt.getSource(); combo.hidePopup(); } }); ###@###.### 2002-05-31

EVALUATION Currently, keyboard navigation causes the combo box selection to change while keyboard navigating. We have a way of doing lightweight navigation (not public yet) but we can't add it to the API until we get the ok to add public API. I'm changing this to be an RFE. tom.santos@eng 1999-01-25 The semantics for ComboBox is such that the navigational changes correspond to the selection changes (setSelectedItem) and an actionEvent is fired with the value of getActionCommand(). At this stage we will not be changing the semantics of the combo box events. ###@###.### 2002-05-30 After a dialog with Ethan, I think I understand the issue. Specifically, the semantics of Keyboard navigation should be like Mouse navigation. This is further supported by the fact that the combo box as a Table cell editor will perform the desired semantics of not changing selection when using keyboard navigation. There is switching logic in BasicComboBoxUI which takes care of this situation so the solution would be to consolidate this behavour. Perhap the table cell editor semantics can be applied to the Metal LAF and the Windows LAF can retain the old selected item behaviour. The solution is pretty simple but the repurcusions could be enourmous. We may be able to change these semantics for Metal but not for the Windows LAF. In order for these changes to occur we should discuss this issue with a lot of people: HIE, Swing tech lead, Java client architect and some of our partners. ###@###.### 2002-05-31