JDK-6417341 : IE Window becomes Zombie when closed prior to the modal dialog
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-04-24
  • Updated: 2011-01-20
  • Resolved: 2006-10-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.
Other JDK 6
5.0u10 b02Fixed 6Fixed
Related Reports
Relates :  
Relates :  
Description
Run the applet below and press "call dialog" button.

This creates a modal dialog and a new browser window. 

Close the new browser window using the mouse (click "X" at the right upper corner). 

Result: This window does not exit completely and remains in a "zombie" state. You can see the window in the task bar, but if you click on it, it does not come up.

The only way to get rid of this window is to kill IE in the task manager.  

Reproducible with the latest 5.0u7 build. This doesn't happen on 1.4.2

TC05-01_Top.html
----------------
<APPLET CODE="SampleApplet.class" WIDTH=300 HEIGHT=220>
  <PARAM NAME="PAGE" VALUE="TC05-01_Top.html">
</APPLET>

SampleApplet.java
-----------------
import java.awt.*;
import java.awt.event.*;
import java.applet.*;
import javax.swing.*;
import java.net.URL;

public class SampleApplet extends JApplet{
    private JButton jButton1 = new JButton();

    public SampleApplet() {
    }

    public void init() {
        try {
            jbInit();
        }
        catch(Exception e) {
            e.printStackTrace();
        }
    }

    private void jbInit() throws Exception {
        jButton1.setBounds(new Rectangle(56, 98, 135, 38));
        jButton1.setText("Call Dialog");
        jButton1.addActionListener(new java.awt.event.ActionListener() {
            public void actionPerformed(ActionEvent e) {
                jButton1_actionPerformed(e);
            }
        });
        this.getContentPane().setLayout(null);
        this.setSize(new Dimension(400,300));
        this.getContentPane().add(jButton1, null);
    }

    public void start() {
    }

    public void stop() {
    }

    public void destroy() {
    }

    void jButton1_actionPerformed(ActionEvent e) {
        String strOption[] = new String[2];
        strOption[0] = "OK";
        strOption[1] = "Cancel";
		(new ThreadX(this)).start();        
       	
        JOptionPane.showOptionDialog(this, "Hello", "Hello", JOptionPane.DEFAULT_OPTION, 
JOptionPane.PLAIN_MESSAGE, null, strOption, strOption[0]);
    }

    class ThreadX extends Thread{
  
        SampleApplet jap = null;

        ThreadX(SampleApplet jap){
			this.jap = jap;
 		}

  		public void run(){
	        try {
            	Thread.sleep(1000);

   		        this.jap.getAppletContext().showDocument(new URL(this.jap.getCodeBase()+this.jap.getParameter("PAGE")), "_blank");
	        }
   		    catch (Exception ex) {
       		    ex.printStackTrace();
        	}
		}
	}
}
Added two attachements for this zombie windows before and after it happened. (tested with 5u7-b02/XP-pro(sp2) (windows_before_zombie.bmp/windows_zombie_at_close.bmp)

Comments
EVALUATION it seems related to 6417395. Calvin is working a fix for all of this issues from modal dialog. Calvin's fix may fix this bug as well
22-05-2006

EVALUATION Sending WINDOW_CLOSING to applet's embedded frame is not an absolutely correct way to make AWT shutdown. In current modality implementation (at least in 1.4, 1.5 and 1.6) this message is completely ignored for modal blocked windows, either top-level or embedded frames. However, I don't think we should change current behaviour (sending WINDOW_CLOSING) and fix this problem in another way. Just a few more words about the problem. When the new browser window is opened by the call to AppletContext method, the applet in it is put in the same AppContext as the old applet. That leads to the second applet and its embedded frame to be blocked by the modal dialog, so any further WINDOW_CLOSING events for embedded frame are ignored. This is correct with the only exception: the second browser window is *not* blocked and can be closed. The first browser window *is* blocked, so it can't be closed and no WINDOW_CLOSING events are even sent to embedded frame. But this is not true for the second window. So I suggest to fix the bug either by putting the second applet to another AppContext or by blocking the second browser window in the same way as the first window. Using another AppContext is probably the bad idea. I'm not sure if two instances of the same applet can be in separate AppContexts, so I'd recommend the second way. In any case this is not an AWT issue, so I'm dispatching this CR to plugin.
02-05-2006

EVALUATION When user closes the new window, IE calls into plugin, then the Frame containing applet sends out WINDOW_CLSOING to itself. However, when there is an active modal dialog, the WINDOW_CLSOING messages seems not be dispatched to the listener of this message. A EDT bug ?
27-04-2006