JDK-4151025 : Ctrl + i causes unexpected behaviour
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.1.6,1.2.0,1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1998-06-22
  • Updated: 2000-10-23
  • Resolved: 2000-10-23
Related Reports
Duplicate :  
Duplicate :  
Description
The test program below gives different results on 1.2beta4 and 1.1.6

On 1.2 Ctrl + i is ignored, all other accelerators work fine.

On 1.1.6 the program seems to lock up if you pull down the menu and then make 
the menu go away, and then hit ctrl + i.  It does not do this for other
accelerator keystrokes. Also, it doesn't matter whether the accelerator for
the menu item is ctrl + i or not.  Even if you set it to something else, ctrl + i 
still locks it up after the menu has been pulled down at least once. 




import com.sun.java.swing.*; 
import java.awt.event.*; 

public class MenuTest 
{ 
	public MenuTest() 
   	{       
		JFrame frame = new JFrame(); 
      		frame.setSize(200,200);       
		JMenuBar menuBar = new JMenuBar();       
		JMenu menu = new JMenu("File");       
		JMenuItem item = new JMenuItem("Exit");       
		item.addActionListener(new ActionListener()
		{          
			public void actionPerformed(ActionEvent e) 
         		{             
				System.out.println("menu item selected"); 
         		}       
		}); 

      		item.setAccelerator(KeyStroke.getKeyStroke(KeyEvent.VK_I,java.awt.Event.CTRL_MASK));       
		menu.add(item); 
      		menuBar.add(menu);       
		frame.setJMenuBar(menuBar); 
      		frame.show(); 
   	} 
    
	public static void main(String[] args) 
   	{ 
      		new MenuTest();    
	} 
}

======================================================================

Name: wl91122			Date: 09/07/99


9/5/99 eval1127@eng -- fine on Solaris;  problem is win32-specific.  Believe we have a dupe/open bug for this.  This report filed against 1.2.2, but changed to 
kestrel-beta, since behavior still exists there.  Accelerators look DISABLED (on both platforms).

1) run the program
   typing ctrl-i has no effect

2)
public class CtrlI extends javax.swing.JFrame {
	public CtrlI() {
		setTitle("Ctrl-I Accelerator Bug");
		buildGUI ();
		pack ();
	}
	private void buildGUI () {
		menuBar = new javax.swing.JMenuBar ();
		fileMenu = new javax.swing.JMenu ();
		fileMenu.setText ("File");
		ctrli = new javax.swing.JMenuItem ();
		ctrli.setText ("Ctrli");
		ctrli.addActionListener (new java.awt.event.ActionListener () {
		    public void actionPerformed (java.awt.event.ActionEvent evt) {
				javax.swing.JOptionPane.showMessageDialog(null,  "Menu ctrl - I called");
		    }});

		/****************************************/
		/****************************************/
		// $BUG: setting CTRL-I as accelerator does not work in jdk1.2.2 on NT/SP5,
		// typing CTRL-I has no effect
		ctrli.setAccelerator(javax.swing.KeyStroke.getKeyStroke('I',java.awt.Event.CTRL_MASK ));
		/****************************************/
		/****************************************/
		
		fileMenu.add(ctrli);
		fileMenu.addSeparator();
		exitMenu = new javax.swing.JMenuItem ();
		exitMenu.setText ("Exit");
		exitMenu.addActionListener (new java.awt.event.ActionListener () {
		    public void actionPerformed (java.awt.event.ActionEvent evt) {
				javax.swing.JOptionPane.showMessageDialog(null,  "Menu ctrl - X called");
			    System.exit (0);
		    }});
		addWindowListener (new java.awt.event.WindowAdapter () {
			public void windowClosing (java.awt.event.WindowEvent evt) {
			    System.exit (0);
			}});

		// CTRL-X works well
		exitMenu.setAccelerator(javax.swing.KeyStroke.getKeyStroke('X',java.awt.Event.CTRL_MASK ));

		fileMenu.add(exitMenu);
		menuBar.add(fileMenu);
		setJMenuBar(menuBar);
	}
	
	protected javax.swing.JMenuBar menuBar;
	protected javax.swing.JMenu fileMenu;
	protected javax.swing.JMenuItem ctrli;
	protected javax.swing.JMenuItem exitMenu;
	
	public static void main(java.lang.String[] args) {
		new CtrlI ().show ();
	}
}
(Review ID: 94874)
======================================================================

Comments
EVALUATION Note that this happens only when there is no other focusable component -- adding a JTextArea to the frame's content pane makes the bug go away. What seems to be happening is a deadlock in the focusmanager. I'm turning it over to Hania for expert analysis: Full thread dump: "Screen Updater" (TID:0xee70d330, sys_thread_t:0xedf51db8, state:CW) prio=4 java.lang.Object.wait(Object.java) sun.awt.ScreenUpdater.nextEntry(ScreenUpdater.java:70) sun.awt.ScreenUpdater.run(ScreenUpdater.java:90) "AWT-Finalizer" (TID:0xee70a660, sys_thread_t:0xedf81db8, state:CW) prio=9 java.lang.Object.wait(Object.java) sun.awt.AWTFinalizer.run(AWTFinalizer.java:40) "AWT-Motif" (TID:0xee704e80, sys_thread_t:0xedfb1db8, state:CW) prio=5 java.lang.Thread.run(Thread.java) "AWT-Input" (TID:0xee704ac0, sys_thread_t:0xedfe1db8, state:R) prio=5 "AWT-EventQueue-0" (TID:0xee7052c8, sys_thread_t:0xee011db8, state:R) prio=5 *current thread* javax.swing.JComponent.isFocusTraversable(JComponent.java:1378) javax.swing.DefaultFocusManager.getFocusableComponentAfter(DefaultFocusManager.java:164) javax.swing.DefaultFocusManager.focusNextComponent(DefaultFocusManager.java:88) javax.swing.DefaultFocusManager.processKeyEvent(DefaultFocusManager.java:73) javax.swing.JComponent.processKeyEvent(JComponent.java:1419) javax.swing.JMenu.processKeyEvent(JMenu.java:998) java.awt.Component.processEvent(Component.java:2209) java.awt.Container.processEvent(Container.java:904) java.awt.Component.dispatchEventImpl(Component.java:1809) java.awt.Container.dispatchEventImpl(Container.java:949) java.awt.Component.dispatchEvent(Component.java:1741) java.awt.LightweightDispatcher.processKeyEvent(Container.java:1479) java.awt.LightweightDispatcher.dispatchEvent(Container.java:1463) java.awt.Container.dispatchEventImpl(Container.java:936) java.awt.Window.dispatchEventImpl(Window.java:491) java.awt.Component.dispatchEvent(Component.java:1741) java.awt.EventDispatchThread.run(EventDispatchThread.java:79) "Finalizer thread" (TID:0xee700210, sys_thread_t:0xee2c1db8, state:CW) prio=1 "Async Garbage Collector" (TID:0xee700258, sys_thread_t:0xee2f1db8, state:R) prio=1 "Idle thread" (TID:0xee7002a0, sys_thread_t:0xee3c1db8, state:R) prio=0 "Clock" (TID:0xee700088, sys_thread_t:0xee3f1db8, state:CW) prio=12 "main" (TID:0xee7000b0, sys_thread_t:0x39f70, state:CW) prio=5 Monitor Cache Dump: sun.awt.ScreenUpdater@EE70D330/EE7787F0: <unowned> Waiting to be notified: "Screen Updater" (0xedf51db8) sun.awt.motif.MToolkit@EE705348/EE755268: owner "AWT-Input" (0xedfe1db8, 1 entry) Waiting to be notified: "AWT-Motif" (0xedfb1db8) sun.awt.AWTFinalizer@EE70A660/EE770238: <unowned> Waiting to be notified: "AWT-Finalizer" (0xedf81db8) <unknown key> (0xee2f1db8): owner "Async Garbage Collector" (0xee2f1db8, 1 entry) Registered Monitor Dump: Thread queue lock: <unowned> Waiting to be notified: "main" (0x39f70) Name and type hash table lock: <unowned> String intern lock: <unowned> JNI pinning lock: <unowned> JNI global reference lock: <unowned> BinClass lock: <unowned> Class loading lock: <unowned> Java stack lock: <unowned> Code rewrite lock: <unowned> Heap lock: <unowned> Has finalization queue lock: <unowned> Finalize me queue lock: <unowned> Waiting to be notified: "Finalizer thread" (0xee2c1db8) Dynamic loading lock: <unowned> Monitor IO lock: <unowned> Child death monitor: <unowned> Event monitor: <unowned> I/O monitor: <unowned> Alarm monitor: <unowned> Waiting to be notified: "Clock" (0xee3f1db8) Sbrk lock: <unowned> Monitor registry: owner "AWT-EventQueue-0" (0xee011db8, 1 entry) Thread Alarm Q: Here's what I am seeing with jdk1.3: The first test program locks on Solaris 2.7. The second test program seems to work on Solaris 2.7. On Windows, neither works (i.e., pressing ctrl-i produces no effect), and neither locks up). I suspect this is all the result of the interaction of the keyboard shortcut stuff with the focus manager. Since ctrl-i is a TAB, the focus manager gets a crack at it first, I think. In any event, we need to determince what *should* happen, and then fix it. hania.gajewska@Eng 1999-09-16 Name: pzR10082 Date: 10/11/2000 This is not reproducible with Merlin focus API. ###@###.### 2000-10-11 ======================================================================
11-10-2000