JDK-7196264 : [macosx] Dialogs do not receive focus
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86
  • Submitted: 2012-09-05
  • Updated: 2012-12-24
  • Resolved: 2012-12-14
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_08-ea"
Java(TM) SE Runtime Environment (build 1.7.0_08-ea-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.4-b01, mixed mode)

Java Plug-in 10.8.0.05

ADDITIONAL OS VERSION INFORMATION :
Mac OS X 10.7.4

A DESCRIPTION OF THE PROBLEM :
When opening a dialog from a swing applet running on the browser, none of the dialog components has focus. Even when clicking on the dialog, it does not receive any focus.
This only happens when running the applet on the browser.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Because this problem is only visible when the applet runs on the browser, the first step is to create a jar file and an html file that makes use of that jar file.

1. Runs the html file;
2. press the button 'open dialog' to show the dialog;

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
1. When the dialog is shown, the button "Yes" should have the focus.
2. When the JTextField in the dialog is pressed, should receive keyboard focus.
ACTUAL -
1. The Button "Yes" does receive the initial focus;
2. When clicking on the JTextField present on the dialog it does not receive any keyboard focus.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No errors on the Java console.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package com.macosx.tests;

import java.awt.Color;
import java.awt.Dimension;
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.JApplet;
import javax.swing.JButton;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
import javax.swing.JTextField;
import javax.swing.SwingUtilities;

public class AppletDialogExample extends JApplet{

	private JPanel panel;
	private JButton openDialogBtn;
	
	private void doStart()
	{
		panel = new JPanel();
		panel.setPreferredSize(new Dimension(500,500));
		panel.setBackground(Color.GRAY);
		
		openDialogBtn = new JButton("open dialog");
		openDialogBtn.addActionListener(new ActionListener(){

			@Override
			public void actionPerformed(ActionEvent arg0) {
				Runnable run = new Runnable()
				{
					public void run()
					{
						JPanel dialogPanel = new JPanel(new GridLayout(1,1));
						JTextField textField = new JTextField();
						dialogPanel.add(textField);
						
						JOptionPane.showConfirmDialog(null, dialogPanel);
					}
				};
				SwingUtilities.invokeLater(run);
			}
		});
		panel.add(openDialogBtn);
        setContentPane(panel);
	}
	
	@Override
	public void start() {
		try {
			SwingUtilities.invokeAndWait(new Runnable() {
				public void run() {
					doStart();
				}
			});
		} catch (Exception e) {
			throw new RuntimeException(e);
		}
	}
}


<html>
<head>
<title>Menu test Applet</title>
</head>
<body>
<applet id="appletID" height="800" width="600"
  code="com.macosx.tests.AppletDialogExample"
  archive="test.jar">
</applet>
</div>
</body>
</html>
---------- END SOURCE ----------

Comments
duplicate of 8001161
14-12-2012

Also, I think I'd better fix 7124310 first, because fixing it might potentially change focus events flow.
25-10-2012

This is the focus activity we've got when running the applet via appletviewer on OS X (starting right after pressing the "Open dialog" button): 1. WINDOW_OPENED for the dialog window is put into the queue 2. WINDOW_LOST_FOCUS for the applet viewer frame is put into the queue (as the result of the native focus event) 3. WINDOW_GAINED_FOCUS for the dialog is put into the queue (as the result of the native focus event) 4. WINDOW_OPENED is dequeued and handled 5. WINDOW_LOST_FOCUS is dequeued 5.1 WINDOW_DEACTIVATED is put into the queue (as the result of handling WINDOW_LOST_FOCUS in DKFM) 5.2 WINDOW_DEACTIVATED is dequeued and handled 6. WINDOW_GAINED_FOCUS is dequeued 6.1 WINDOW_ACTIVATED is put into the queue (as the result of handling WINDOW_GAINED_FOCUS in DKFM) 6.2 WINDOW_ACTIVATED is dequeued and handled 6.3 Focus is requested on the dialog's "Yes" button 6.3.1 WINDOW_GAINED_FOCUS for the dialog is put into the queue (by LWWindowPeer.requestWindowFocus/changeFocusedWindow) 7. WINDOW_GAINED_FOCUS is finally dispatched to BasicOptionPaneUI 8. Focus is requested on the dialog's "Yes" button (by BasicOptionPaneUI.selectInitialValue) 8.1 FOCUS_GAINED for the dialo'g "Yes" is dequeued and handled 9. WINDOW_GAINED_FOCUS is dequeued and handled Now, to the focus activity we've got when running the applet via Firefox on OS X (starting right after pressing the "Open dialog" button): 1. WINDOW_OPENED for the dialog window is put into the queue 2. WINDOW_OPENED is dequeued and handled 3. WINDOW_GAINED_FOCUS for the dialog is put into the queue (as the result of the native focus event). Note that we haven't got WINDOW_LOST_FOCUS for the applet frame as in the first scenario. This seems to be important. 4. WINDOW_GAINED_FOCUS is dequeued 4.1 WINDOW_LOST_FOCUS for the applet frame is put into the queue (as the result of handling WINDOW_GAINED_FOCUS in DKFM) 4.2 WINDOW_LOST_FOCUS is dequeued 4.2.1 FOCUS_LOST event for the applet's frame "Open dialog" button is dequeued and handled 4.3 WINDOW_ACTIVATED for the dialog is put into the queue (as the result of handling WINDOW_GAINED_FOCUS in DKFM) 4.4 WINDOW_ACTIVATED is dequeued 4.4.1 WINDOW_DEACTIVATED for the applet's frame is put into the queue (as the result of handling WINDOW_ACTIVATED in DKFM) 4.4.2 WINDOW_DEACTIVATED is dequeued and handled 4.5 Focus is requested on the dialog's "Yes" button 4.5.1 WINDOW_GAINED_FOCUS for the dialog is put into the queue (by LWWindowPeer.requestWindowFocus/changeFocusedWindow) 5. WINDOW_GAINED_FOCUS is finally dispatched to BasicOptionPaneUI 6. Focus is requested on the dialog's "Yes" button (by BasicOptionPaneUI.selectInitialValue) 6.1 FOCUS_GAINED for the dialo'g "Yes" button is dequeued and handled 7. This is again important. PluginEmbeddedFrame calls CEmbeddedFrame.handleWindowFocusEvent to let it know that it is no longer active. As the result, WINDOW_LOST_FOCUS for the applet's frame is put into the queue 8. Things go bad So, it looks like the late arrival of the WINDOW_LOST_FOCUS confuses focus subsystem somehow. I'm not sure what the correct fix is, though. Ignore that WINDOW_LOST_FOCUS becuase it has already been synthesized on 4.1? Do not ignore it, but make sure that our focus subsystem doesn't get confused by it? Tell deploy guys to stop sending us events when it's too late? Need to investigate more.
25-10-2012

Confirming that it's a bug. It's only reproducible when running in browser, when running via appletviewer everything works fine.
25-10-2012